Damage detection from multi-view visual data

ABSTRACT

A plurality of images may be analyzed to determine an object model. The object model may have a plurality of components, and each of the images may correspond with one or more of the components. Component condition information may be determined for one or more of the components based on the images. The component condition information may indicate damage incurred by the object portion corresponding with the component.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority under 35 U.S.C. 120 to U.S. patentapplication Ser. No. 17/174,250, filed Feb. 11, 2021, titled “DAMAGEDETECTION FROM MULTI-VIEW VISUAL DATA”, which claims priority under 35U.S.C. 120 to U.S. patent application Ser. No. 16/692,133, filed Nov.22, 2019, titled “DAMAGE DETECTION FROM MULTI-VIEW VISUAL DATA”, nowU.S. Pat. No. 10,950,033, Issued on Mar. 16, 2021, which claims priorityunder 35 U.S.C. 120 to U.S. Provisional Patent Application No.62/795,421, titled “AUTOMATIC VEHICLE DAMAGE DETECTION FROM MULTI-VIEWVISUAL DATA”, filed Jan. 22, 2019, by Holzer et al., both of which arehereby incorporated by reference in their entirety and for all purposes.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure as it appears in the United States Patent andTrademark Office patent file or records but otherwise reserves allcopyright rights whatsoever.

TECHNICAL FIELD

The present disclosure relates generally to the detection of damage onan object, and more specifically to automatic detection of damage basedon multi-view data.

DESCRIPTION OF RELATED ART

Vehicles need to be inspected for damage on different occasions. Forexample, a vehicle may be inspected after an accident to evaluate orsupport an insurance claim or police report. As another example, avehicle may be inspected before and after the rental of a vehicle, orbefore buying or selling a vehicle.

Vehicle inspection using conventional approaches is a largely manualprocess. Typically, a person walks around the vehicle and manually notesdamage and conditions. This process is time-intensive, resulting insignificant costs. The manual inspection results also vary based on theperson. For example, a person may be more or less experienced inevaluating damage. The variation in results can yield a lack of trustand potential financial losses, for example when buying and sellingvehicles or when evaluating insurance claims.

Overview

According to various embodiments, techniques and mechanisms describedherein provide for systems, devices, methods, and machine readable mediafor detecting damage to objects. In some implementations, an objectmodel may be determined for a designated object from a first pluralityof images of the object. Each of the first plurality of images may becaptured from a respective viewpoint. The object model may include aplurality of object model components. Each of the images may correspondwith one or more of the object model components. Each of the objectmodel components may correspond with a respective portion of thedesignated object. Respective component condition information may bedetermined for one or more of the object model components based on theplurality of images. The component condition information may indicate acharacteristic of damage incurred by the respective object portioncorresponding with the object model component. The component conditioninformation may be stored on a storage device.

In some implementations, the object model may include athree-dimensional skeleton of the designated object. Determining theobject model may include applying a neural network to estimate one ormore two-dimensional skeleton joints for a respective one of theplurality of images. Alternately, or additionally, determining theobject model may include estimating pose information for a designatedone of the plurality of images, the pose information may include alocation and angle of the camera with respect to the designated objectfor the designated image. Alternately, or additionally, determining theobject model may include determining the three-dimensional skeleton ofthe designated object based on the two-dimensional skeleton joints andthe pose information. The object model components may be determinedbased at least in part on the three-dimensional skeleton of thedesignated object.

According to various embodiments, a designated one of the object modelcomponents may correspond with a designated subset of the images and adesignated portion of the object. A multi-view representation of thedesignated portion of the object may be constructed at the computingdevice based on the designated subset of the images. The multi-viewrepresentation may be navigable in one or more directions. Thecharacteristic may be one or more of an estimated probability of damageto the respective object portion, an estimated severity of damage to therespective object portion, and an estimated type of damage to therespective object portion.

In some embodiments, aggregated object condition information may bedetermined based on the component condition information. The aggregatedobject condition information may indicate damage to the object as awhole. Based on the aggregated object condition information, a standardview of the object that may include a visual representation of damage tothe object may be determined. The visual representation of damage to theobject may be a heatmap. The standard view of the object may include oneor more of a top-down view of the object, a multi-view representation ofthe object navigable in one or more directions, and a three-dimensionalmodel of the object.

According to various embodiments, determining the component conditioninformation may involve applying a neural network to a subset of theimages corresponding with the respective object model component. Theneural network may receive as an input depth information captured from adepth sensor at the computing device. Determining the componentcondition information may involve aggregating neural network resultscomputed for separate images corresponding with the respective objectmodel component.

In some implementations, live recording guidance for capturing one ormore additional images via the camera may be provided. Thecharacteristic may include a statistical estimate, and the liverecording guidance may be provided so as to decrease statisticaluncertainty for the statistical estimate.

In some embodiments, a multi-view representation of the designatedobject may be constructed at the computing device based on the pluralityof images. The multi-view representation may be navigable in one or moredirections.

In some implementations, the object may be a vehicle, and the objectmodel may include a three-dimensional skeleton of the vehicle. Theobject model components may include each of a left vehicle door, a rightvehicle door, and a windshield.

BRIEF DESCRIPTION OF THE DRAWINGS

The patent or application file contains at least one drawing executed incolor. Copies of this patent or patent application publication withcolor drawing(s) will be provided by the Office upon request and paymentof the necessary fee.

The included drawings are for illustrative purposes and serve only toprovide examples of possible structures and operations for the disclosedinventive systems, apparatus, methods and computer program products forimage processing. These drawings in no way limit any changes in form anddetail that may be made by one skilled in the art without departing fromthe spirit and scope of the disclosed implementations.

FIG. 1 illustrates one example of a damage detection method, performedin accordance with one or more embodiments.

FIG. 2 illustrates an example of a damage representation, generated inaccordance with one or more embodiments.

FIG. 3 illustrates one example of a damage detection data capturemethod, performed in accordance with various embodiments.

FIG. 4 illustrates a method for component-level damage detection,performed in accordance with various embodiments.

FIG. 5 illustrates an object-level damage detection method, performed inaccordance with one or more embodiments.

FIG. 6 illustrates one example of a damage detection aggregation method,performed in accordance with one or more embodiments.

FIG. 7 illustrates a particular example of a damage detectionaggregation method, performed in accordance with one or moreembodiments.

FIG. 8 illustrates one example of a method for performing geometricanalysis of a perspective view image, performed in accordance with oneor more embodiments.

FIG. 9 illustrates one example of a method for performing perspectiveimage to top-down view mapping, performed in accordance with one or moreembodiments.

FIG. 10 illustrates one example of a method for performing top-down viewto perspective image mapping, performed in accordance with one or moreembodiments.

FIG. 11 illustrates a method for analyzing object coverage, performed inaccordance with one or more embodiments.

FIG. 12 illustrates an example of the mapping of 20 points from thetop-down image of a vehicle to a perspective frame, generated inaccordance with one or more embodiments.

FIG. 13 , FIG. 14 , and FIG. 15 illustrate images processed inaccordance with one or more embodiments.

FIGS. 16 and 17 illustrate examples perspective view images on whichdamage has been detected, processed in accordance with one or moreembodiments.

FIG. 18 illustrates a particular example of a 2D image of a 3D model onwhich damage has been mapped, processed in accordance with one or moreembodiments.

FIG. 19 illustrates one example of a top-down image on which damage hasbeen mapped and represented as a heatmap in accordance with one or moreembodiments.

FIG. 20 illustrates a particular example of a perspective view image,processed in accordance with one or more embodiments.

FIG. 21 illustrates one example of a 3D model of a perspective viewimage, analyzed in accordance with one or more embodiments.

FIG. 22 illustrates one example a top-down image on which damage hasbeen mapped and represented as a heatmap, processed in accordance withone or more embodiments.

FIG. 23 illustrates a particular example of a top-down image that hasbeen mapped to a perspective view image, processed in accordance withone or more embodiments.

FIG. 24 illustrates an example of a MVIDMR acquisition system,configured in accordance with one or more embodiments.

FIG. 25 illustrates one example of a method for generating a MVIDMR,performed in accordance with one or more embodiments.

FIG. 26 illustrates one example of multiple camera views fused togetherinto a three-dimensional (3D) model.

FIG. 27 illustrates one example of separation of content and context ina MVIDMR.

FIGS. 28A-28B illustrate examples of concave and convex views, whereboth views use a back-camera capture style.

FIGS. 29A-29B illustrates one example of a back-facing, concave MVIDMR,generated in accordance with one or more embodiments.

FIGS. 30A-30B illustrate examples of front-facing, concave and convexMVIDMRs generated in accordance with one or more embodiments.

FIG. 31 illustrates one example of a method for generating virtual dataassociated with a target using live image data, performed in accordancewith one or more embodiments.

FIG. 32 illustrates one example of a method for generating MVIDMRs,performed in accordance with one or more embodiments.

FIGS. 33A and 33B illustrate some aspects of generating an AugmentedReality (AR) image capture track for capturing images used in a MVIDMR.

FIG. 34 illustrates one example of generating an Augmented Reality (AR)image capture track for capturing images used in a MVIDMR on a mobiledevice.

FIGS. 35A and 35B illustrate examples of generating an Augmented Reality(AR) image capture track including status indicators for capturingimages used in a MVIDMR.

FIG. 36 illustrates a particular example of a computer system configuredin accordance with various embodiments.

DETAILED DESCRIPTION

According to various embodiments, techniques and mechanisms describedherein may be used to identify and represent damage to an object such asa vehicle. The damage detection techniques may be employed by untrainedindividuals. For example, an individual may collect multi-view data ofan object, and the system may detect the damage automatically.

According to various embodiments, various types of damage may bedetected. For a vehicle, such data may include, but is not limited to:scratches, dents, flat tires, cracked glass, broken glass, or other suchdamage.

In some implementations, a user may be guided to collect multi-view datain a manner that reflects the damage detection process. For example,when the system detects that damage may be present, the system may guidethe user to take additional images of the portion of the object that isdamaged.

According to various embodiments, techniques and mechanisms describedherein may be used to create damage estimates that are consistent overmultiple captures. In this way, damage estimates may be constructed in amanner that is independent of the individual wielding the camera anddoes not depend on the individual's expertise. In this way, the systemcan automatically detect damage in an instant, without requiring humanintervention.

Although various techniques and mechanisms are described herein by wayof example with reference to detecting damage to vehicles, thesetechniques and mechanisms are widely applicable to detecting damage to arange of objects. Such objects may include, but are not limited to:houses, apartments, hotel rooms, real property, personal property,equipment, jewelry, furniture, offices, people, and animals.

FIG. 1 illustrates a method 100 for damage detection. According tovarious embodiments, the method 100 may be performed at a mobilecomputing device such as a smart phone. The smart phone may be incommunication with a remote server. Alternately, or additionally, someor all of the method 100 may be performed at a remote computing devicesuch as a server. The method 100 may be used to detect damage to any ofvarious types of objects. However, for the purpose of illustration, manyexamples discussed herein will be described with reference to vehicles.

At 102, multi-view data of an object is captured. According to variousembodiments, the multi-view data may include images captured fromdifferent viewpoints. For example, a user may walk around a vehicle andcapture images from different angles. In some configurations, themulti-view data may include data from various types of sensors. Forexample, the multi-view data may include data from more than one camera.As another example, the multi-view data may include data from a depthsensor. As another example, the multi-view data may include datacollected from an inertial measurement unit (IMU). IMU data may includeposition information, acceleration information, rotation information, orother such data collected from one or more accelerometers or gyroscopes.

In particular embodiments, the multi-view data may be aggregated toconstruct a multi-view representation. Additional details regardingmulti-view data collection, multi-view representation construction, andother features are discussed in co-pending and commonly assigned U.S.patent application Ser. No. 15/934,624, “Conversion of an InteractiveMulti-view Image Data Set into a Video”, by Holzer et al., filed Mar.23, 2018, which is hereby incorporated by reference in its entirety andfor all purposes.

At 104, damage to the object is detected based on the capturedmulti-view data. In some implementations, the damage may be detected byevaluating some or all of the multi-view data with a neural network, bycomparing some or all of the multi-view data with reference data, and/orany other relevant operations for damage detection. Additional detailsregarding damage detection are discussed throughout the application.

At 106, a representation of the detected damage is stored on a storagemedium or transmitted via a network. According to various embodiments,the representation may include some or all of a variety of information.For example, the representation may include an estimated dollar value.As another example, the representation may include a visual depiction ofthe damage. As still another example, a list of damaged parts may beprovided. Alternatively, or additionally, the damaged parts may behighlighted in a 3D CAD model.

In some embodiments, a visual depiction of the damage may include animage of actual damage. For example, once the damage is identified at104, one or more portions of the multi-view data that include images ofthe damaged portion of the object may be selected and/or cropped.

In some implementations, a visual depiction of the damage may include anabstract rendering of the damage. An abstract rendering may include aheatmap that shows the probability and/or severity of damage using acolor scale. Alternatively, or additionally, an abstract rendering mayrepresent damage using a top-down view or other transformation. Bypresenting damage on a visual transformation of the object, damage (orlack thereof) to different sides of the object may be presented in astandardized manner.

FIG. 2 presents an example of a damage representation, generated inaccordance with one or more embodiments. The damage representation shownin FIG. 2 includes a top-down view of the vehicle, as well as views fromother perspectives. Damage to the vehicle may be represented on thetop-down view in various ways, for instance by the color red. Inaddition, the damage representation may include perspective view imagesof portions of the vehicle, such as those in which damage appears.

FIG. 3 illustrates a method 300 of damage detection data capture.According to various embodiments, the method 300 may be performed at amobile computing device such as a smart phone. The smart phone may be incommunication with a remote server. The method 300 may be used to detectdamage to any of various types of objects. However, for the purpose ofillustration, many examples discussed herein will be described withreference to vehicles.

A request to capture input data for damage detection for an object isreceived at 302. In some implementations, the request to capture inputdata may be received at a mobile computing device such as a smart phone.In particular embodiments, the object may be a vehicle such as a car,truck, or sports utility vehicle.

An object model for damage detection is determined at 304. According tovarious embodiments, the object model may include reference data for usein evaluating damage and/or collecting images of an object. For example,the object model may include one or more reference images of similarobjects for comparison. As another example, the object model may includea trained neural network. As yet another example, the object model mayinclude one or more reference images of the same object captured at anearlier point in time. As yet another example, the object model mayinclude a 3D model (such as a CAD model) or a 3D mesh reconstruction ofthe corresponding vehicle.

In some embodiments, the object model may be determined based on userinput. For example, the user may identify a vehicle in general or a car,truck, or sports utility vehicle in particular as the object type.

In some implementations, the object model may be determinedautomatically based on data captured as part of the method 300. In thiscase, the object model may be determined after the capturing of one ormore images at 306.

At 306, an image of the object is captured. According to variousembodiments, capturing the image of the object may involve receivingdata from one or more of various sensors. Such sensors may include, butare not limited to, one or more cameras, depth sensors, accelerometers,and/or gyroscopes. The sensor data may include, but is not limited to,visual data, motion data, and/or orientation data. In someconfigurations, more than one image of the object may be captured.Alternatively, or additionally, video footage may be captured.

According to various embodiments, a camera or other sensor located at acomputing device may be communicably coupled with the computing devicein any of various ways. For example, in the case of a mobile phone orlaptop, the camera may be physically located within the computingdevice. As another example, in some configurations a camera or othersensor may be connected to the computing device via a cable. As stillanother example, a camera or other sensor may be in communication withthe computing device via a wired or wireless communication link.

According to various embodiments, as used herein the term “depth sensor”may be used to refer to any of a variety of sensor types that may beused to determine depth information. For example, a depth sensor mayinclude a projector and camera operating in infrared light frequencies.As another example, a depth sensor may include a projector and cameraoperating in visible light frequencies. For instance, a line-laser orlight pattern projector may project a visible light pattern onto anobject or surface, which may then be detected by a visible light camera.

One or more features of the captured image or images are extracted at308. In some implementations, extracting one or more features of theobject may involve constructing a multi-view capture that presents theobject from different viewpoints. If a multi-view capture has alreadybeen constructed, then the multi-view capture may be updated based onthe new image or images captured at 306. Alternatively, or additionally,feature extraction may involve performing one or more operations such asobject recognition, component identification, orientation detection, orother such steps.

At 310, the extracted features are compared with the object model.According to various embodiments, comparing the extracted features tothe object model may involve making any comparison suitable fordetermining whether the captured image or images are sufficient forperforming damage comparison. Such operations may include, but are notlimited to: applying a neural network to the captured image or images,comparing the captured image or images to one or more reference images,and/or performing any of the operations discussed with respect to FIGS.4 and 5 .

A determination is made at 312 as to whether to capture an additionalimage of the object. In some implementations, the determination may bemade at least in part based on an analysis of the one or more imagesthat have already been captured.

In some embodiments, a preliminary damage analysis may be implementedusing as input the one or more images that have been captured. If thedamage analysis is inconclusive, then an additional image may becaptured. Techniques for conducting damage analysis are discussed inadditional detail with respect to the methods 400 and 500 shown in FIGS.4 and 5 .

In some embodiments, the system may analyze the captured image or imagesto determine whether a sufficient portion of the object has beencaptured in sufficient detail to support damage analysis. For example,the system may analyze the capture image or images to determine whetherthe object is depicted from all sides. As another example, the systemmay analyze the capture image or images to determine whether each panelor portion of the object is shown in a sufficient amount of detail. Asyet another example, the system may analyze the capture image or imagesto determine whether each panel or portion of the object is shown from asufficient number of viewpoints.

If the determination is made to capture an additional image, then at 314image collection guidance for capturing the additional image isdetermined. In some implementations, the image collection guidance mayinclude any suitable instructions for capturing an additional image thatmay assist in changing the determination made at 312. Such guidance mayinclude an indication to capture an additional image from a targetedviewpoint, to capture an additional image of a designated portion of theobject, or to capture an additional image at a different level ofclarity or detail. For example, if possible damage is detected, thenfeedback may be provided to capture additional detail at the damagedlocation.

At 316, image collection feedback is provided. According to variousembodiments, the image collection feedback may include any suitableinstructions or information for assisting a user in collectingadditional images. Such guidance may include, but is not limited to,instructions to collect an image at a targeted camera position,orientation, or zoom level. Alternatively, or additionally, a user maybe presented with instructions to capture a designated number of imagesor an image of a designated portion of the object.

For example, a user may be presented with a graphical guide to assistthe user in capturing an additional image from a target perspective. Asanother example, a user may be presented with written or verbalinstructions to guide the user in capturing an additional image.Additional techniques for determining and providing recording guidanceas well as other related features are described in co-pending andcommonly assigned U.S. patent application Ser. No. 15/992,546, titled“Providing Recording Guidance in Generating a Multi-View InteractiveDigital Media Representation”, filed May 30, 2018 by Holzer et al.

When it is determined to not capture an additional image of the object,then at 318 the captured image or images are stored. In someimplementations, the captured images may be stored on a storage deviceand used to perform damage detection, as discussed with respect to themethods 400 and 500 in FIGS. 4 and 5 . Alternatively, or additionally,the images may be transmitted to a remote location via a networkinterface.

FIG. 4 illustrates a method 400 for component-level damage detection.According to various embodiments, the method 400 may be performed at amobile computing device such as a smart phone. The smart phone may be incommunication with a remote server. The method 400 may be used to detectdamage to any of various types of objects. However, for the purpose ofillustration, many examples discussed herein will be described withreference to vehicles.

A skeleton is extracted from input data at 402. According to variousembodiments, the input data may include visual data collected asdiscussed with respect to the method 300 shown in FIG. 3 .Alternatively, or additionally, the input data may include previouslycollected visual data, such as visual data collected without the use ofrecording guidance.

In some implementations, the input data may include one or more imagesof the object captured from different perspectives. Alternatively, oradditionally, the input data may include video data of the object. Inaddition to visual data, the input data may also include other types ofdata, such as IMU data.

According to various embodiments, skeleton detection may involve one ormore of a variety of techniques. Such techniques may include, but arenot limited to: 2D skeleton detection using machine learning, 3D poseestimation, and 3D reconstruction of a skeleton from one or more 2Dskeletons and/or poses. Additional details regarding skeleton detectionand other features are discussed in co-pending and commonly assignedU.S. patent application Ser. No. 15/427,026, titled “Skeleton Detectionand Tracking via Client-server Communication” by Holzer et al, filedFeb. 7, 2017, which is hereby incorporated by reference in its entiretyand for all purposes.

Calibration image data associated with the object is identified at 404.According to various embodiments, the calibration image data may includeone or more reference images of similar objects or of the same object atan earlier point in time. Alternatively, or additionally, thecalibration image data may include a neural network used to identifydamage to the object.

A skeleton component is selected for damage detection at 406. In someimplementations, a skeleton component may represent a panel of theobject. In the case of a vehicle, for example, a skeleton component mayrepresent a door panel, a window, or a headlight. Skeleton componentsmay be selected in any suitable order, such as sequentially, randomly,in parallel, or by location on the object.

According to various embodiments, when a skeleton component is selectedfor damage detection, a multi-view capture of the skeleton component maybe constructed. Constructing a multi-view capture of the skeletoncomponent may involve identifying different images in the input datathat capture the skeleton component from different viewpoints. Theidentified images may then be selected, cropped, and combined to producea multi-view capture specific to the skeleton component.

A viewpoint of the skeleton component is selected for damage detectionat 404. In some implementations, each viewpoint included in themulti-view capture of the skeleton component may be analyzedindependently. Alternatively, or additionally, more than one viewpointmay be analyzed simultaneously, for instance by providing the differentviewpoints as input data to a machine learning model trained to identifydamage to the object. In particular embodiments, the input data mayinclude other types of data, such as 3D visual data or data capturedusing a depth sensor or other type of sensor.

According to various embodiments, one or more alternatives to skeletonanalysis at 402-410 may be used. For example, an object part (e.g.,vehicle component) detector may be used to directly estimate the objectparts. As another example, an algorithm such as a neural network may beused to map an input image to a top-down view of an object such as avehicle (and vice versa) in which the components are defined. As yetanother example, an algorithm such as a neural network that classifiesthe pixels of an input image as a specific component can be used toidentify the components. As still another example, component-leveldetectors may be used to identify specific components of the object. Asyet another alternative, a 3D reconstruction of the vehicle may becomputed and a component classification algorithm may be run on that 3Dmodel. The resulting classification can then be back-projected into eachimage. As still another alternative, a 3D reconstruction of the vehiclecan be computed and fitted to an existing 3D CAD model of the vehicle inorder to identify the single components.

At 410, the calibration image data is compared with the selectedviewpoint to detect damage to the selected skeleton component. Accordingto various embodiments, the comparison may involve applying a neuralnetwork to the input data. Alternatively, or additionally, an imagecomparison between the selected viewpoint and one or more referenceimages of the object captured at an earlier point in time may beperformed.

A determination is made at 412 as to whether to select an additionalviewpoint for analysis. According to various embodiments, additionalviewpoints may be selected until all available viewpoints are analyzed.Alternatively, viewpoints may be selected until the probability ofdamage to the selected skeleton component has been identified to adesignated degree of certainty.

Damage detection results for the selected skeleton component areaggregated at 414. According to various embodiments, damage detectionresults from different viewpoints to a single damage detection resultper panel resulting in a damage result for the skeleton component. Forexample, a heatmap may be created that shows the probability and/orseverity of damage to a vehicle panel such as a vehicle door. Accordingto various embodiments, various types of aggregation approaches may beused. For example, results determined at 410 for different viewpointsmay be averaged. As another example, different results may be used to“vote” on a common representation such as a top-down view. Then, damagemay be reported if the votes are sufficiently consistent for the panelor object portion.

A determination is made at 416 as to whether to select an additionalskeleton component for analysis. In some implementations, additionalskeleton components may be selected until all available skeletoncomponents are analyzed.

Damage detection results for the object are aggregated at 414. Accordingto various embodiments, damage detection results for differentcomponents may be aggregated into a single damage detection result forthe object as a whole. For example, creating the aggregated damageresults may involve creating a top-down view, as shown in FIG. 11 . Asanother example, creating the aggregated damage results may involveidentifying standardized or appropriate viewpoints of portions of theobject identified as damaged, as shown in FIG. 11 . As yet anotherexample, creating the aggregated damage results may involve taggingdamaged portions in a multi-view representation. As still anotherexample, creating the aggregated damage results may involve overlaying aheatmap on a multi-view representation. As yet another example, creatingthe aggregated damage results may involve selecting affected parts andpresenting them to the user. Presenting may be done as a list, ashighlighted elements in a 3D CAD model, or in any other suitablefashion.

In particular embodiments, techniques and mechanisms described hereinmay involve a human to provide additional input. For example, a humanmay review damage results, resolve inconclusive damage detectionresults, or select damage result images to include in a presentationview. As another example, human review may be used to train one or moreneural networks to ensure that the results computed are correct and areadjusted as necessary.

FIG. 5 illustrates an object-level damage detection method 500,performed in accordance with one or more embodiments. The method 500 maybe performed at a mobile computing device such as a smart phone. Thesmart phone may be in communication with a remote server. The method 500may be used to detect damage to any of various types of objects.

Evaluation image data associated with the object is identified at 502.According to various embodiments, the evaluation image data may includesingle images captured from different viewpoints. As discussed herein,the single images may be aggregated into a multi-view capture, which mayinclude data other than images, such as IMU data.

An object model associated with the object is identified at 504. In someimplementations, the object model may include a 2D or 3D standardizedmesh, model, or abstracted representation of the object. For instance,the evaluation image data may be analyzed to determine the type ofobject that is represented. Then, a standardized model for that type ofobject may be retrieved. Alternatively, or additionally, a user mayselect an object type or object model to use. The object model mayinclude a top-down view of the object.

Calibration image data associated with the object is identified at 506.According to various embodiments, the calibration image data may includeone or more reference images. The reference images may include one ormore images of the object captured at an earlier point in time.Alternatively, or additionally, the reference images may include one ormore images of similar objects. For example, a reference image mayinclude an image of the same type of car as the car in the images beinganalyzed.

In some implementations, the calibration image data may include a neuralnetwork trained to identify damage. For instance, the calibration imagedata may be trained to analyze damage from the type of visual dataincluded in the evaluation data.

The calibration data is mapped to the object model at 508. In someimplementations, mapping the calibration data to the object model mayinvolve mapping a perspective view of an object from the calibrationimages to a top-down view of the object.

The evaluation image data is mapped to the object model at 510. In someimplementations, mapping the evaluation image data to the object modelmay involve determine a pixel-by-pixel correspondence between the pixelsof the image data and the points in the object model. Performing such amapping may involve determining the camera position and orientation foran image from IMU data associated with the image.

In some embodiments, a dense per-pixel mapping between an image and thetop-down view may be estimated at 510. Alternatively, or additionally,location of center of an image may be estimated with respect to thetop-down view. For example, a machine learning algorithm such as deepnet may be used to map the image pixels to coordinates in the top-downview. As another example, joints of a 3D skeleton of the object may beestimated and used to define the mapping. As yet another example,component-level detectors may be used to identify specific components ofthe object.

In some embodiments, the location of one or more object parts within theimage may be estimated. Those locations may then be used to map datafrom the images to the top-down view. For example, object parts may beclassified on a pixel-wise basis. As another example, the centerlocation of object parts may be determined. As another example, thejoints of a 3D skeleton of an object may be estimated and used to definethe mapping. As yet another example, component-level detectors may beused for specific object components.

In some implementations, images may be mapped in a batch via a neuralnetwork. For example, a neural network may receive as input a set ofimages of an object captured from different perspectives. The neuralnetwork may then detect damage to the object as a whole based on the setof input images.

The mapped evaluation image data is compared to the mapped calibrationimage data at 512 to identify any differences. According to variousembodiments, the data may be compared by running a neural network on amulti-view representation as a whole. Alternatively, or additional, theevaluation and image data may be compared on an image-by-image basis.

If it is determined at 514 that differences are identified, then at 516a representation of the identified differences is determined. Accordingto various embodiments, the representation of the identified differencesmay involve a heatmap of the object as a whole. For example, a heatmapof a top-down view of a vehicle showing damage is illustrated in FIG. 2. Alternatively, one or more components that are damaged may be isolatedand presented individually.

At 518, a representation of the detected damage is stored on a storagemedium or transmitted via a network. In some implementations, therepresentation may include an estimated dollar value. Alternatively, oradditionally, the representation may include a visual depiction of thedamage. Alternatively, or additionally, affected parts may be presentedas a list and/or highlighted in a 3D CAD model.

In particular embodiments, damage detection of an overall objectrepresentation may be combined with damage representation on one or morecomponents of the object. For example, damage detection may be performedon a closeup of a component if an initial damage estimation indicatesthat damage to the component is likely.

FIG. 6 illustrates a method 600 for aggregating detected damage to anobject, performed in accordance with one or more embodiments. Accordingto various embodiments, the method 600 may be performed at a mobilecomputing device such as a smart phone. The smart phone may be incommunication with a remote server. Alternately, or additionally, someor all of the method 600 may be performed at a remote computing devicesuch as a server. The method 600 may be used to detect damage to any ofvarious types of objects. However, for the purpose of illustration, manyexamples discussed herein will be described with reference to vehicles.

A request to detect damage to an object is received at 606. In someimplementations, the request to detect damage may be received at amobile computing device such as a smart phone. In particularembodiments, the object may be a vehicle such as a car, truck, or sportsutility vehicle.

In some implementations, the request to detect damage may include orreference input data. The input data may include one or more images ofthe object captured from different perspectives. Alternatively, oradditionally, the input data may include video data of the object. Inaddition to visual data, the input data may also include other types ofdata, such as IMU data.

An image is selected for damage aggregation analysis at 604. Accordingto various embodiments, the image may be captured at a mobile computingdevice such as a mobile phone. In some instances, the image may be aview in a multi-view capture. A multi-view capture may include differentimages of the object captured from different perspectives. For instance,different images of the same object may be captured from differentangles and heights relative to the object.

In some implementations, images may be selected in any suitable order.For example, images may be analyzed sequentially, in parallel, or insome other order. As another example, images may be analyzed live asthey are captured by a mobile computing device, or in order of theircapture.

In particular embodiments, selecting an image for analysis may involvecapturing an image. According to various embodiments, capturing theimage of the object may involve receiving data from one or more ofvarious sensors. Such sensors may include, but are not limited to, oneor more cameras, depth sensors, accelerometers, and/or gyroscopes. Thesensor data may include, but is not limited to, visual data, motiondata, and/or orientation data. In some configurations, more than oneimage of the object may be captured. Alternatively, or additionally,video footage may be captured.

At 606, damage to the object is detected. According to variousembodiments, damage may be detected by applying a neural network to theselected image. The neural network may identify damage to the objectincluded in the image. In particular embodiments, the damage may berepresented as a heatmap. The damage information may identify the damagetype and/or severity. For example, the damage information may identifydamage as being light, moderate, or severe. As another example, thedamage information may identify the damage as a dent or a scratch.

A mapping of the selected perspective view image to a standard view isdetermined at 608, and detected damage is mapped to the standard view at610. In some embodiments, the standard view may be determined based onuser input. For example, the user may identify a vehicle in general or acar, truck, or sports utility vehicle in particular as the object type.

In particular embodiments, a standard view may be determined byperforming object recognition on the object represented in theperspective view image. The object type may then be used to select astandard image for that particular object type. Alternately, a standardview specific to the object represented in the perspective view may beretrieved. For example, a top-down view, 2D skeleton, or 3D model may beconstructed for the object at an earlier point in time before damage hasoccurred.

In some embodiments, damage mapping may be performed by using themapping of the selected perspective view image to the standard view tomap the damage detected at 606 to the standard view. For example,heatmap colors may be mapped from the perspective view to theircorresponding locations on the standard view. As another example, damageseverity and/or type information may be mapped from the perspective viewto the standard view in a similar fashion.

In some implementations, a standard view may be a top-down view of theobject that shows the top and the sides of the object. A mappingprocedure may then map each point in the image to a corresponding pointin the top-down view. Alternately, or additionally, a mapping proceduremay map each point in the top-down view to a corresponding point in theperspective view image.

In some embodiments, a neural network may estimate 2D skeleton jointsfor the image. Then, a predefined mapping may be used to map from theperspective view image to the standard image (e.g., the top-down view).For instance, the predefined mapping may be defined based on trianglesdetermined by the 2D joints.

In some implementations, a neural network may predict a mapping betweena 3D model (such as a CAD model) and the selected perspective viewimage. The damage may then be mapped to, and aggregated on, the texturemap of the 3D model. In particular embodiments, the constructed andmapped 3D model may then be compared with a ground truth 3D model.

According to various embodiments, the ground truth 3D model may be astandard 3D model for all objects of the type represented, or may beconstructed based on an initial set of perspective view images capturedbefore damage is detected. Comparisons of the reconstructed 3D model tothe expected 3D model may be used as an additional input source orweight during aggregate damage estimation. Such techniques may be usedin conjunction with live, pre-recorded, or guided image selection andanalysis.

According to various embodiments, skeleton detection may involve one ormore of a variety of techniques. Such techniques may include, but arenot limited to: 2D skeleton detection using machine learning, 3D poseestimation, and 3D reconstruction of a skeleton from one or more 2Dskeletons and/or poses. Additional details regarding skeleton detectionand other features are discussed in co-pending and commonly assignedU.S. patent application Ser. No. 15/427,026, titled “Skeleton Detectionand Tracking via Client-server Communication” by Holzer et al, filedFeb. 7, 2017, which is hereby incorporated by reference in its entiretyand for all purposes.

Damage information is aggregated on the standard view at 616. Accordingto various embodiments, aggregating damage on the standard view mayinvolve combining the damage mapped at operation 610 with damage mappedfor other perspective view images. For example, damage values for thesame component from different perspective view images may be summed,averaged, or otherwise combined.

In some implementations, aggregating damage on the standard view mayinvolve creating a heatmap or other visual representation on thestandard view. For example, damage to a portion of the object may berepresented by changing the color of that portion of the object in thestandard view.

According to various embodiments, aggregating damage on the standardview may involve mapping damage back to one or more perspective viewimages. For instance, damage to a portion of the object may bedetermined by aggregating damage detection information from severalperspective view images. That aggregated information may then be mappedback to the perspective view images. Once mapped back, the aggregatedinformation may be included as a layer or overlay in an independentimage and/or a multi-view capture of the object.

Damage probability information is updated based on the selected image at614. According to various embodiments, the damage probabilityinformation may identify a degree of certainty with which detecteddamage is ascertained. For instance, in a given perspective view it maybe difficult to determine with certainty whether a particular image ofan object portion depicts damage to the object or glare from a reflectedlight source. Accordingly, detected damage may be assigned a probabilityor other indication of certainty. However, the probability may beresolved to a value closer to zero or one with analysis of differentperspective views of the same object portion.

In particular embodiments, the probability information for aggregateddamage information in standard view may be updated based on from whichviews the damage was detected. For example, damage likelihood mayincrease if it is detected from multiple viewpoints. As another example,damage likelihood may increase if it is detected from one or moreclose-up views. As another example, damage likelihood may decrease ifdamage is only detected in one viewpoint but not in others. As yetanother example, different results may be used to “vote” on a commonrepresentation.

If the determination is made to capture an additional image, then at 616guidance for additional viewpoint capture is provided. In someimplementations, the image collection guidance may include any suitableinstructions for capturing an additional image that may assist inresolving uncertainty. Such guidance may include an indication tocapture an additional image from a targeted viewpoint, to capture anadditional image of a designated portion of the object, or to capture anadditional image at a different level of clarity or detail. For example,if possible damage is detected, then feedback may be provided to captureadditional detail at the damaged location.

In some implementations, the guidance for additional viewpoint capturemay be provided so as to resolve damage probability information asdiscussed with respect to the operation 614. For example, if the damageprobability information is very high (e.g., 90+%) or very low (e.g.,10−%) for a given object component, additional viewpoint capture may beunnecessary. However, if damage probability information is relativelyindeterminate (e.g., 50%), then capturing an additional image may helpto resolve the damage probability.

In particular embodiments, the thresholds for determining whether toprovide guidance for an additional image may be strategically determinedbased on any of a variety of considerations. For example, the thresholdmay be determined based on the number of images of the object or objectcomponent that have been previously captured. As another example, thethreshold may be specified by a systems administrator.

According to various embodiments, the image collection feedback mayinclude any suitable instructions or information for assisting a user incollecting additional images. Such guidance may include, but is notlimited to, instructions to collect an image at a targeted cameraposition, orientation, or zoom level. Alternatively, or additionally, auser may be presented with instructions to capture a designated numberof images or an image of a designated portion of the object.

For example, a user may be presented with a graphical guide to assistthe user in capturing an additional image from a target perspective. Asanother example, a user may be presented with written or verbalinstructions to guide the user in capturing an additional image.Additional techniques for determining and providing recording guidanceas well as other related features are described in co-pending andcommonly assigned U.S. patent application Ser. No. 15/992,546, titled“Providing Recording Guidance in Generating a Multi-View InteractiveDigital Media Representation”, filed May 30, 2018 by Holzer et al.

At 618, a determination is made as to whether to select an additionalimage for analysis. In some implementations, the determination may bemade at least in part based on an analysis of the one or more imagesthat have already been captured. If the damage analysis is inconclusive,then an additional image may be captured for analysis. Alternately, eachavailable image may be analyzed.

In some embodiments, the system may analyze the captured image or imagesto determine whether a sufficient portion of the object has beencaptured in sufficient detail to support damage analysis. For example,the system may analyze the capture image or images to determine whetherthe object is depicted from all sides. As another example, the systemmay analyze the capture image or images to determine whether each panelor portion of the object is shown in a sufficient amount of detail. Asyet another example, the system may analyze the capture image or imagesto determine whether each panel or portion of the object is shown from asufficient number of viewpoints.

When it is determined to not select an additional image for analysis,then at 660 the damage information is stored. For example, the damageinformation may be stored on a storage device. Alternatively, oradditionally, the images may be transmitted to a remote location via anetwork interface.

In particular embodiments, the operations shown in FIG. 6 may beperformed in an order different than that shown. For example, damage tothe object may be detected at 606 after mapping an image to a standardview at 610. In this way, the damage detection procedure may be tailoredto the particular portion of the object reflected in the image.

In some implementations, the method shown in FIG. 6 may include one ormore operations other than those shown in FIG. 6 . For example, thedamage detection operation discussed with respect to 606 may include oneor more procedures for identifying the object or object componentincluded in the selected image. Such a procedure may include, forinstance, a neural network trained to identify object components.

FIG. 7 illustrates a method 700 for aggregating detected damage to anobject, performed in accordance with one or more embodiments. Accordingto various embodiments, the method 700 may be performed at a mobilecomputing device such as a smart phone. The smart phone may be incommunication with a remote server. The method 700 may be used to detectdamage to any of various types of objects. However, for the purpose ofillustration, many examples discussed herein will be described withreference to vehicles.

FIG. 7 may be used to perform live aggregation of damage detection. Bydoing a live aggregation of damage detection, the system may obtain abetter estimate on which parts of a car are damaged and which aren't.Additionally, based on this the system can guide the user directly tocapture more data in order to improve the estimate. According to variousembodiments, one or more of the operations discussed with respect toFIG. 7 may be substantially similar to corresponding operationsdiscussed with respect to FIG. 6 .

A request to detect damage to an object is received at 702. In someimplementations, the request to detect damage may be received at amobile computing device such as a smart phone. In particularembodiments, the object may be a vehicle such as a car, truck, or sportsutility vehicle.

In some implementations, the request to detect damage may include orreference input data. The input data may include one or more images ofthe object captured from different perspectives. Alternatively, oradditionally, the input data may include video data of the object. Inaddition to visual data, the input data may also include other types ofdata, such as IMU data.

A 3D representation of the object based on a multi-view image isdetermined at 704. According to various embodiments, the multi-viewrepresentation may be predetermined and retrieved at 704. Alternately,the multi-view representation may be created at 704. For instance, themulti-view representation may be created based on input data collectedat a mobile computing device.

In some implementations, the multi-view representation may be a360-degree view of the object. Alternately, the multi-viewrepresentation may be a partial representation of the object. Accordingto various embodiments, the multi-view representation may be used toconstruct a 3D representation of the object. For example, 3D skeletondetection may be performed on the multi-view representation including aplurality of images.

At 706, recording guidance for capturing an image for damage analysis isprovided. In some implementations, the recording guidance may guide auser to position a camera to one or more specific positions. Images maythen be captured from these positions. The recording guidance may beprovided in any of a variety of ways. For example, the user may beguided to position the camera to align with one or more perspective viewimages in a pre-recorded multi-view capture of a similar object. Asanother example, the user may be guided to position the camera to alignwith one or more perspective views of a three-dimensional model.

An image for performing damage analysis is captured at 708. According tovarious embodiments, the recording guidance may be provided as part of alive session for damage detection and aggregation. The recordingguidance may be used to align the live camera view at the mobilecomputing device with the 3D representation.

In some implementations, recording guidance may be used to guide a userto capture a specific part of an object in a specific way. For example,recording guidance may be used to guide a user to capture a closeup ofthe left front door of a vehicle.

Damage information from the captured image is determined at 710.According to various embodiments, damage may be detected by applying aneural network to the selected image. The neural network may identifydamage to the object included in the image. In particular embodiments,the damage may be represented as a heatmap. The damage information mayidentify the damage type and/or severity. For example, the damageinformation may identify damage as being light, moderate, or severe. Asanother example, the damage information may identify the damage as adent or a scratch.

The damage information is mapped onto a standard view at 712. Accordingto various embodiments, mobile device and/or camera alignmentinformation may be used to map damage detection data onto a 3Drepresentation. Alternately, or additionally, a 3D representation may beused to map detected damage onto the top-down view. For example, apre-recorded multi-view capture, predetermined 3D model, or dynamicallydetermined 3D model may be used to create a mapping from one or moreperspective view images to the standard view.

The damage information is aggregated on the standard view at 714. Insome implementations, aggregating damage on the standard view mayinvolve creating a heatmap or other visual representation on thestandard view. For example, damage to a portion of the object may berepresented by changing the color of that portion of the object in thestandard view.

According to various embodiments, aggregating damage on the standardview may involve mapping damage back to one or more perspective viewimages. For instance, damage to a portion of the object may bedetermined by aggregating damage detection information from severalperspective view images. That aggregated information may then be mappedback to the perspective view images. Once mapped back, the aggregatedinformation may be included as a layer or overlay in an independentimage and/or a multi-view capture of the object.

At 716, a determination is made as to whether to capture an additionalimage for analysis. According to various embodiments, additional imagesmay be captured for analysis until enough data is captured that thedegree of certainty about detected damage falls above or below adesignated threshold. Alternately, additional images may be captured foranalysis until the device stops recording.

When it is determined to not select an additional image for analysis,then at 718 the damage information is stored. For example, the damageinformation may be stored on a storage device. Alternatively, oradditionally, the images may be transmitted to a remote location via anetwork interface.

In particular embodiments, the operations shown in FIG. 7 may beperformed in an order different than that shown. For example, damage tothe object may be detected at 710 after mapping an image to a standardview at 712. In this way, the damage detection procedure may be tailoredto the particular portion of the object reflected in the image.

In some implementations, the method shown in FIG. 7 may include one ormore operations other than those shown in FIG. 7 . For example, thedamage detection operation discussed with respect to 710 may include oneor more procedures for identifying the object or object componentincluded in the selected image. Such a procedure may include, forinstance, a neural network trained to identify object components.

FIG. 8 illustrates one example of a method 800 for performing geometricanalysis of a perspective view image, performed in accordance with oneor more embodiments. The method 800 may be performed on any suitablecomputing device. For example, the method 800 may be performed on amobile computing device such as a smart phone. Alternately, oradditionally, the method 800 may be performed on a remote server incommunication with a mobile computing device.

A request to construct a top-down mapping of an object is received at802. According to various embodiments, the request may be received at auser interface. At 804, a video or image set of the object captured fromone or more perspectives is identified. The video or image set isreferred to herein as “source data”. According to various embodiments,the source data may include a 360-degree view of the object.Alternately, the source data may include a view that has less than360-degree coverage.

In some embodiments, the source data may include data captured from acamera. For example, the camera may be located on a mobile computingdevice such a mobile phone. As another example, one or more traditionalcameras may be used to capture such information.

In some implementations, the source data may include data collected froman inertial measurement unit (IMU). IMU data may include informationsuch as camera location, camera angle, device velocity, deviceacceleration, or any of a wide variety of data collected fromaccelerometers or other such sensors.

The object is identified at 806. In some implementations, the object maybe identified based on user input. For example, a user may identify theobject as a vehicle or person via a user interface component such as adrop-down menu.

In some embodiments, the object may be identified based on imagerecognition. For example, the source data may be analyzed to determinethat the subject of the source data is a vehicle, a person, or anothersuch object. The source data may include a variety of image data.However, in case of a multi-view capture the source data focuses in aparticular object from different viewpoints, the image recognitionprocedure may identify commonalities between the different perspectiveviews to isolate the object that is the subject of the source data fromother objects that are present in some portion of the source data butnot in other portions of the source data.

At 808, vertices and faces of a 2D mesh are defined in the top-down viewof the object. According to various embodiments, each face may representa part of the object surface that could be approximated as being planar.For example, when a vehicle is captured in the source data, thevehicle's door panel or roof may be represented as a face in a 2D meshbecause the door and roof are approximately planar despite beingslightly curved.

In some embodiments, vertices and faces of a 2D mesh may be identifiedby analyzing the source data. Alternately, or additionally, theidentification of the object at 206 may allow for the retrieval of apredetermined 2D mesh. For example, a vehicle object may be associatedwith a default 2D mesh that may be retrieved upon request.

Visibility angles are determined for each vertex of the object at 810.According to various embodiments, a visibility angle indicates the rangeof object angles with respect to the camera for which the vertex isvisible. In some embodiments, visibility angles of a 2D mesh may beidentified by analyzing the source data. Alternately, or additionally,the identification of the object at 806 may allow for the retrieval ofpredetermined visibility angle along with a predetermined 2D mesh. Forexample, a vehicle object may be associated with a default 2D mesh withassociated visibility angle that may be retrieved upon request.

A 3D skeleton of the object is constructed at 812. According to variousembodiments, constructing a 3D skeleton may involve any of a variety ofoperations. For example, 2D skeleton detection may be performed on everyframe using a machine learning procedure. As another example, 3D camerapose estimation may be performed to determine a location and angle ofthe camera with respect to the object for a particular frame. As yetanother example, a 3D skeleton may be reconstructed from 2D skeletonsand or poses. Additional details regarding skeleton detection arediscussed in co-pending and commonly assigned U.S. patent applicationSer. No. 15/427,026, titled “Skeleton Detection and Tracking viaClient-server Communication” by Holzer et al, filed Feb. 7, 2017, whichis hereby incorporated by reference in its entirety and for allpurposes.

FIG. 9 illustrates one example of a method 900 for performingperspective image to top-down view mapping, performed in accordance withone or more embodiments. In some embodiments, the method 900 may beperformed to map each pixel of an object represented in a perspectiveview to the corresponding point in a predefined top-down view of thatclass of objects.

The method 900 may be performed on any suitable computing device. Forexample, the method 900 may be performed on a mobile computing devicesuch as a smart phone. Alternately, or additionally, the method 900 maybe performed on a remote server in communication with a mobile computingdevice.

A request to construct a top-down mapping of an object is received at902. According to various embodiments, the request may be generatedafter the performance of geometric analysis as discussed with respect tothe method 800 shown in FIG. 8 . The request may identify one or moreimages for which to perform the top-down mapping.

A 3D mesh for the image to top-down mapping is identified at 904. The 3Dmesh may provide a three-dimensional representation of the object andserve as an intervening representation between the actual perspectiveview image and the top-down view.

At 906, a pixel in the perspective frame is selected for analysis.According to various embodiments, pixels may be selected in any suitableorder. For example, pixels may be selected sequentially. As anotherexample, pixels may be selected based on characteristics such aslocation or color. Such a selection process may facilitate fasteranalysis by focusing the analysis on portions of the image most likelyto be present in the 3D mesh.

The pixel is projected onto the 3D mesh at 908. In some implementations,projecting the pixel onto the 3D mesh may involve simulating a cameraray passing by the pixel position in the image plan and into the 3Dmesh. Upon simulating such a camera ray, barycentric coordinates of theintersection point with respect to the vertices of the intersection facemay be extracted.

A determination is made at 910 as to whether the pixel intersects withthe object 3D mesh. If the pixel does not intersect with the object 3Dmesh, then at 912 the pixel is set as belonging to the background. Ifinstead the pixel does intersect with the object 3D mesh, then at 914 amapped point is identified for the pixel. According to variousembodiments, a mapped point may be identified by applying thebarycentric coordinates as weights for the vertices of the correspondingintersection face in the top-down image.

In some embodiments, a machine learning approach may be used to performimage to top-down mapping on a single image. For example, a machinelearning algorithm such as deep net may be run on the perspective imageas a whole. The machine learning algorithm may identify 2D locations ofeach pixel (or a subset of them) in the top-down image.

In some implementations, a machine learning approach may be used toperform top-down to image mapping. For example, given a perspectiveimage and a point of interest in the top-down image, the machinelearning algorithm may be run on the perspective image for identifyingthe top-down locations of its points. Then, the point of interest in thetop-down image may be mapped to the perspective image.

In some embodiments, mapping the point of interest in the top-down imageto the perspective image may involve first selecting the points in theperspective image whose top-down mapping is closest to the interestpoint. Then, the selected points in the perspective image may beinterpolated.

Examples of an image to top-down mapping are shown in FIGS. 13, 14, and15 . The locations of pixels in images of vehicle components arerepresented by colored dots. These dot locations are mapped from fixedlocations 1302 in the perspective view to corresponding locations 1304on the top-down view 1306. FIG. 14 shows a similar arrangement, withfixed locations 1402 in the perspective view mapped to correspondinglocations 1404 in the top-down view 1406. For example, in FIG. 13 , thecolor coding corresponds to the location of the points in the image. Asimilar procedure may be performed in reverse to map from the top-downview to the perspective view.

In some implementations, a point of interest may be mapped as a weightedaverage of nearby points. For example, in FIG. 15 , the mapping of anyparticular point, such as 1502, may depend on the value of nearbypoints, such as 1504 and 1506, drawn from the mapped location inperspective view.

Returning to FIG. 9 , as an alternative to operations 906-910, theprojections of the 3D skeleton joints faces may be used together withthe corresponding joints and faces in the top-down view to directlydefine image transformations that map pixel information from theperspective views into the top-down view and vice versa.

A determination is made at 916 as to whether to select an additionalpixel for analysis. According to various embodiments, analysis maycontinue until all pixels or a suitable number of pixels are mapped. Asdiscussed with respect to operation 906, pixels may be analyzed insequence, in parallel, or in any suitable order.

Optionally, the computed pixel values are aggregated at 918. Accordingto various embodiments, aggregating the computing pixel values mayinvolve, for example, storing a cohesive pixel map on a storage deviceor memory module.

According to various embodiments, one or more of the operations shown inFIG. 9 may be omitted. For example, a pixel may be ignored rather thansetting it as a background pixel at 912. In some implementations, one ormore of the operations may be performed in an order different from thatshown in FIG. 9 . For example, pixel values may be aggregatedcumulatively during pixel analysis. As another example, pixel values maybe determined in parallel.

FIG. 10 illustrates one example of a method 1000 for performing top-downview to perspective image mapping, performed in accordance with one ormore embodiments. According to various embodiments, top-down to imagemapping refers to finding in a perspective image the position pointsfrom a top-down image.

The method 1000 may be performed on any suitable computing device. Forexample, the method 1000 may be performed on a mobile computing devicesuch as a smart phone. Alternately, or additionally, the method 1000 maybe performed on a remote server in communication with a mobile computingdevice.

At 1002, a request to perform top-down to image mapping is received fora perspective frame. At 1004, a 2D mesh and 3D mesh are identified. forthe perspective image to top-down mapping. A 3D mesh is also referred toherein as a 3D skeleton.

At 1006, a point in the top-down image is selected for analysis.According to various embodiments, points may be selected in any suitableorder. For example, points may be selected sequentially. As anotherexample, points may be selected based on characteristics such aslocation. For example, points may be selected within a designated facebefore moving on to the next face of the top-down image.

At 1008, an intersection of the point with the 2D mesh is identified. Adetermination is then made at 1010 as to whether the intersection faceis visible in the frame. According to various embodiments, thedetermination may be made in part by checking one or more visibilityranges determined in the preliminary step for the vertices of theintersection face. If the intersection face is not visible, then thepoint may be discarded.

If the intersection face is visible, then at 1012 coordinates for theintersection point are determined. According to various embodiments,determining coordinate points may involve, for example, extractingbarycentric coordinates for the point with respect to the vertices ofthe intersection face.

A corresponding position on the 3D object mesh is determined at 1014.According to various embodiments, the position may be determined byapplying the barycentric coordinates as weights for the vertices of thecorresponding intersection face in the object 3D mesh.

The point is projected from the mesh to the perspective frame at 1016.In some implementations, projecting the point may involve evaluating thecamera pose and/or the object 3D mesh for the frame. For example, thecamera pose may be used to determine an angle and/or position of thecamera to facilitate the point projection.

FIG. 11 illustrates a method for analyzing object coverage, performed inaccordance with one or more embodiments. According to variousembodiments, the method 1100 may be performed at a mobile computingdevice such as a smart phone. The smart phone may be in communicationwith a remote server. The method 1100 may be used to detect coverage ina set of images and/or a multi-view representation of any of varioustypes of objects. However, for the purpose of illustration, manyexamples discussed herein will be described with reference to vehicles.

A request to determine coverage of an object is received at 1102. Insome implementations, the request to determine coverage may be receivedat a mobile computing device such as a smart phone. In particularembodiments, the object may be a vehicle such as a car, truck, or sportsutility vehicle.

In some implementations, the request to determine coverage may includeor reference input data. The input data may include one or more imagesof the object captured from different perspectives. Alternatively, oradditionally, the input data may include video data of the object. Inaddition to visual data, the input data may also include other types ofdata, such as IMU data.

One or more images are pre-processed at 1104. According to variousembodiments, one or more images may be pre-processed in order to performoperations such as skeleton detection, object recognition, or 3D meshreconstruction. For some such operations, input data from more than oneperspective view image may be used.

In some implementations, skeleton detection may involve one or more of avariety of techniques. Such techniques may include, but are not limitedto: 2D skeleton detection using machine learning, 3D pose estimation,and 3D reconstruction of a skeleton from one or more 2D skeletons and/orposes. Additional details regarding skeleton detection and otherfeatures are discussed in co-pending and commonly assigned U.S. patentapplication Ser. No. 15/427,026, titled “Skeleton Detection and Trackingvia Client-server Communication” by Holzer et al, filed Feb. 7, 2017,which is hereby incorporated by reference in its entirety and for allpurposes.

According to various embodiments, a 3D representation of an object suchas a 3D mesh, potentially with an associated texture map, may bereconstructed. Alternately, the 3D representation may be a mesh based ona 3D skeleton that has a mapping to the top-down mapping defined. Whengenerating a 3D mesh representation, per-frame segmentation and/or spacecarving based on estimated 3D poses of the cameras corresponding tothose frames may be performed. In the case of a 3D skeleton, suchoperations may be performed using a neural network that directlyestimates a 3D skeleton for a given frame or from a neural network thatestimates 2D skeleton joint locations for each frame and then use posesfor all camera viewpoints to triangulate the 3D skeleton.

According to various embodiments, a standard 3D model may be used forall objects of the type represented, or may be constructed based on aninitial set of perspective view images captured before damage isdetected. Such techniques may be used in conjunction with live,pre-recorded, or guided image selection and analysis.

An image is selected for object coverage analysis at 1106. According tovarious embodiments, the image may be captured at a mobile computingdevice such as a mobile phone. In some instances, the image may be aview in a multi-view capture. A multi-view capture may include differentimages of the object captured from different perspectives. For instance,different images of the same object may be captured from differentangles and heights relative to the object.

In some implementations, images may be selected in any suitable order.For example, images may be analyzed sequentially, in parallel, or insome other order. As another example, images may be analyzed live asthey are captured by a mobile computing device, or in order of theircapture.

In particular embodiments, selecting an image for analysis may involvecapturing an image. According to various embodiments, capturing theimage of the object may involve receiving data from one or more ofvarious sensors. Such sensors may include, but are not limited to, oneor more cameras, depth sensors, accelerometers, and/or gyroscopes. Thesensor data may include, but is not limited to, visual data, motiondata, and/or orientation data. In some configurations, more than oneimage of the object may be captured. Alternatively, or additionally,video footage may be captured.

A mapping of the selected perspective view image to a standard view isdetermined at 1108. In some embodiments, the standard view may bedetermined based on user input. For example, the user may identify avehicle in general or a car, truck, or sports utility vehicle inparticular as the object type.

In some implementations, a standard view may be a top-down view of theobject that shows the top and the sides of the object. A mappingprocedure may then map each point in the image to a corresponding pointin the top-down view. Alternately, or additionally, a mapping proceduremay map each point in the top-down view to a corresponding point in theperspective view image.

According to various embodiments, a standard view may be determined byperforming object recognition. The object type may then be used toselect a standard image for that particular object type. Alternately, astandard view specific to the object represented in the perspective viewmay be retrieved. For example, a top-down view, 2D skeleton, or 3D modelmay be constructed for the object.

In some embodiments, a neural network may estimate 2D skeleton jointsfor the image. Then, a predefined mapping may be used to map from theperspective view image to the standard image (e.g., the top-down view).For instance, the predefined mapping may be defined based on trianglesdetermined by the 2D joints.

In some implementations, a neural network may predict a mapping betweena 3D model (such as a CAD model) and the selected perspective viewimage. The coverage may then be mapped to, and aggregated on, thetexture map of the 3D model.

Object coverage for the selected image is determined at 1110. Accordingto various embodiments, object coverage may be determined by analyzingthe portion of the standard view on which the perspective view image hasbeen mapped.

As another example, an object or top-down image of an object may bedivided into a number of components or portions. A vehicle, forinstance, may be divided into doors, a windshield, wheels, and othersuch parts. For each part to which at least a portion of the perspectiveview image has been mapped, a determination may be made as to whetherthe part is sufficiently covered by the image. This determination mayinvolve operations such as determining whether any sub-portions of theobject component are lacking a designated number of mapped pixels.

In particular embodiments, object coverage may be determined byidentifying an area that includes some or all of the mapped pixels. Theidentified area may then be used to aggregate coverage across differentimages.

In some embodiments, a grid or other set of guidelines may be overlaidon the top-down view. The grid may be composed of identical rectanglesor other shapes. Alternately, the grid may be composed of portions ofdifferent sizes. For example, in the image shown in FIG. 14 , portionsof the object that include greater variation and detail, such as theheadlights, are associated with relatively smaller grid portions.

In some implementations, grid density may represent a tradeoff betweenvarious considerations. For example, if the grid is too fine, then falsenegative errors may occur because noise in perspective view imagemapping may mean many grid cells are incorrectly identified as not beingrepresented in the perspective view image because no pixels are mappedto the grid cell. However, if the grid is too coarse, then falsepositive errors may occur because relatively many pixels may map to alarge grid portion even if a subportion of the large grid portion is notadequately represented.

In particular embodiments, the size of a grid portion may bestrategically determined based on characteristics such as the imageresolution, computing device processing power, number of images, levelof detail in the object, feature size at a particular object portion, orother such considerations.

In particular embodiments, an indication of coverage evaluation may bedetermined for the selected image for each grid portion. The indicationof coverage evaluation may include one or more components. For example,the indication of coverage evaluation may include a primary value suchas a probability value identifying a probability that a given gridportion is represented in the selected image. As another example, theindication of coverage evaluation may include a secondary value such asan uncertainty value or standard error value identifying a degree ofuncertainty surrounding the primary value. A value included in anindication of coverage may be modeled as a continuous, discrete, orbinary value.

In particular embodiments, an uncertainty value or standard error valuemay be used to aggregate across different frames. For example, a lowdegree of confidence about the coverage of the front right door from aparticular image would lead to a high uncertainty value, which may leadto a lower weight attributed to the particular image while determiningaggregate coverage of the front right door.

In some implementations, the indication of coverage evaluation for aselected image and a given grid portion may be affected by any of avariety of considerations. For example, a given grid portion may beassociated with a relatively higher probability of coverage in aselected image if the selected image includes a relatively higher numberof pixels that map to the given grid portion. As another example, apixel may be up-weighted in terms of its effect on coverage estimationif the image or image portion in which the pixel is included is capturedfrom a relatively closer distance to the object. As yet another example,a pixel may be down-weighted in terms of its effect on coverageestimation if the image or image portion in which the pixel is includedis captured from an oblique angle. In contrast, a pixel may beup-weighted in terms of its effect on coverage estimation if the imageor image portion in which the pixel is included is captured from anglecloser to 90 degrees.

In particular embodiments, a probability value and an uncertainty valuefor a grid may depend on factors such as the number and probability ofpixel values assigned to the grid cell. For example, if N pixels end upin a grid cell with their associated scores, the probability of coveragemay be modeled as the mean probability score of the N pixels, while theuncertainty value may be modeled as the standard deviation of the Npixels. As another example, if N pixels end up in a grid cell with theirassociated scores, the probability of coverage may be modeled as N timesthe mean probability score of the N pixels, while the uncertainty valuemay be modeled as the standard deviation of the N pixels.

At 1112, a determination is made as to whether to select an additionalimage for analysis. According to various embodiments, each image may beanalyzed in sequence, in parallel, or in any suitable order.Alternately, or additionally, images may be analyzed until one or morecomponent-level and/or aggregate coverage levels meet a designatedthreshold.

An aggregated coverage estimate is determined for the selected object at1114. In some embodiments, determining an aggregated coverage estimatemay involve overlaying on the standard view of the object differentpixel mappings determined at 1108 for different images. Then, the sametypes of techniques discussed with respect to operation 1110 may beperformed on the overlaid standard view image. However, such techniquesmay suffer from the drawback that pixel mappings may be noisy, sodifferent images may randomly have some number of pixels mapped to thesame object portion.

According to various embodiments, determining an aggregated coverageestimate may involve combining coverage areas determined at 1110 fordifferent images. For example, for each grid portion a determination maybe made as to whether any image captures the grid portion with aprobability that exceeds a designated threshold. As another example, aweighted average of the coverage indications may be determined for eachgrid portion to aggregate the image-level coverage estimations.

In some implementations, determining an aggregated coverage estimate mayinvolve evaluating different object components. A determination may bemade for each component as to whether the component has been captured ina sufficient level of detail or clarity. For example, different gridportions associated with an object component such as a wheel or a doormay be combined to determine a coverage indication for the component asa whole. As another example, grid-level heatmaps may be smoothed outover a given object component to determine a component-level objectcoverage estimate.

In some implementations, determining an aggregated coverage estimate mayinvolve determining an object-level coverage estimate. For example, adetermination may be made as to whether the mapped pixels from allperspective views are sufficiently dense over all or designated portionsof the object.

In some implementations, determining an aggregated coverage estimate mayinvolve determining whether a portion of the object has been capturedfrom a designated perspective or at a designated distance. For example,an image or image portion of an object portion captured from a distanceoutside a designated distance range and/or a designated angular rangemay be down-weighted or ignored when determining image coverage.

In some implementations, the aggregated coverage estimate may beimplemented as a heat map. The heat map may be on the grid level, or maybe smoothed out.

In some embodiments, the aggregated coverage estimate may be modulatedin one or more ways. For example, a coverage estimate may be computedspecifically for visual data captured within, below, or above adesignated coverage range. As another example, a coverage estimate maybe computed specifically for visual data captured within, below, orabove a designated angular distance of the object surface relative tothe camera.

In particular embodiments, a modulated coverage estimate may begenerated and stored in a way that is adjustable. For example, a usermay slide a slider affordance in a user interface to adjust the minimumdistance, maximum distance, minimum angle, and/or maximum angle forevaluating coverage.

A determination is made at 1116 as to whether to capture an additionalimage. If the determination is made to capture an additional image, thenat 1118 guidance for additional viewpoint capture is provided. At 1120,one or more images are captured based on the recording guidance. In someimplementations, the image collection guidance may include any suitableinstructions for capturing an additional image that may assist inimproving coverage. Such guidance may include an indication to capturean additional image from a targeted viewpoint, to capture an additionalimage of a designated portion of the object, or to capture an additionalimage at a different level of clarity or detail. For example, ifcoverage of a particular portion of the object is inadequate or missing,then feedback may be provided to capture additional detail at the objectportion for which coverage is lacking.

In some implementations, the guidance for additional viewpoint capturemay be provided so as to improve object coverage as discussed withrespect to the operation 1110 and 1114. For example, if the coverage ofan object or object portion is very high, additional viewpoint capturemay be unnecessary. However, if the coverage of the object or a portionof the object is low, then capturing an additional image may help toimprove the coverage

In particular embodiments, one or more thresholds for determiningwhether to provide guidance for an additional image may be strategicallydetermined based on any of a variety of considerations. For example, thethreshold may be determined based on the number of images of the objector object component that have been previously captured. As anotherexample, the threshold may be specified by a systems administrator. Asyet another example, additional images may be captured until images fromeach of a set of designated perspective viewpoints have been captured.

According to various embodiments, the image collection feedback mayinclude any suitable instructions or information for assisting a user incollecting additional images. Such guidance may include, but is notlimited to, instructions to collect an image at a targeted cameraposition, orientation, or zoom level. Alternatively, or additionally, auser may be presented with instructions to capture a designated numberof images or an image of a designated portion of the object.

For example, a user may be presented with a graphical guide to assistthe user in capturing an additional image from a target perspective. Asanother example, a user may be presented with written or verbalinstructions to guide the user in capturing an additional image.Additional techniques for determining and providing recording guidanceas well as other related features are described in co-pending andcommonly assigned U.S. patent application Ser. No. 15/992,546, titled“Providing Recording Guidance in Generating a Multi-View InteractiveDigital Media Representation”, filed May 30, 2018 by Holzer et al.

In some embodiments, the system may analyze the captured image or imagesto determine whether a sufficient portion of the object has beencaptured in sufficient detail to support damage analysis. For example,the system may analyze the capture image or images to determine whetherthe object is depicted from all sides. As another example, the systemmay analyze the capture image or images to determine whether each panelor portion of the object is shown in a sufficient amount of detail. Asyet another example, the system may analyze the capture image or imagesto determine whether each panel or portion of the object is shown from asufficient number of viewpoints.

When it is determined to not select an additional image for analysis,then at 1122 the coverage information is stored. For example, thecoverage information may be stored on a storage device. Alternatively,or additionally, the images may be transmitted to a remote location viaa network interface.

In some implementations, the method shown in FIG. 11 may include one ormore operations other than those shown in FIG. 11 . For example, themethod 1100 may include one or more procedures for identifying theobject or object component included in the selected image. Such aprocedure may include, for instance, a neural network trained toidentify object components.

In particular embodiments techniques and mechanisms described herein maybe used in conjunction with damage detection analysis. According tovarious embodiments, damage may be detected by applying a neural networkto the selected image. The neural network may identify damage to theobject included in the image. In particular embodiments, the damage maybe represented as a heatmap. The damage information may identify thedamage type and/or severity. For example, the damage information mayidentify damage as being light, moderate, or severe. As another example,the damage information may identify the damage as a dent or a scratch.Detected damage may then be mapped from the perspective view to thestandard view.

According to various embodiments, damage information may be aggregatedon the standard view. Aggregating damage on the standard view mayinvolve combining the damage mapped for one perspective view with damagemapped for other perspective view images. For example, damage values forthe same component from different perspective view images may be summed,averaged, or otherwise combined.

According to various embodiments, the damage probability information maybe determined. Damage probability information may identify a degree ofcertainty with which detected damage is ascertained. For instance, in agiven perspective view it may be difficult to determine with certaintywhether a particular image of an object portion depicts damage to theobject or glare from a reflected light source. Accordingly, detecteddamage may be assigned a probability or other indication of certainty.However, the probability may be resolved to a value closer to zero orone with analysis of different perspective views of the same objectportion.

FIG. 12 illustrates an example of the mapping of 20 points from thetop-down image of a vehicle to a perspective frame. In FIG. 12 , pointsin red such as point 1 1202 are identified as visible in the perspectiveframe and are thus correctly mapped, while points in blue such as point8 1204 are not mapped since they are not visible in the perspectiveview.

FIGS. 16-23 show various images and user interfaces that may begenerated, analyzed, or presented in conjunction with techniques andmechanisms described herein, according to one or more embodiments. FIG.16 shows a perspective view image on which damage has been detected. Thedetected damage is represented with a heatmap. FIG. 17 shows a differentperspective view image. FIG. 18 shows a 2D image of a 3D model on whichdamage has been mapped. The damage is represented in FIG. 18 as red.FIG. 19 shows a top-down image on which damage has been mapped andrepresented as a heatmap. FIG. 20 shows a different perspective viewimage. FIG. 21 shows a 3D model of the perspective view image. In FIG.21 , different surfaces of the object are represented by differentcolors. FIG. 22 shows a top-down image on which damage has been mappedand represented as a heatmap.

FIG. 23 shows a different top-down image that has been mapped to aperspective view image. In FIG. 23 , the middle image on the right isthe input image, the upper image on the right indicates the color-codedlocation of each pixel in the input image, and the image on the leftshows how the pixels in the input image are mapped onto the top-downview. The lower image on the right shows color coded object components,such as a rear windshield and lower rear door panel.

Various embodiments described herein relate generally to systems andmethods for analyzing the spatial relationship between multiple imagesand video together with location information data, for the purpose ofcreating a single representation, a MVIDMR, which eliminates redundancyin the data, and presents a user with an interactive and immersiveactive viewing experience. According to various embodiments, active isdescribed in the context of providing a user with the ability to controlthe viewpoint of the visual information displayed on a screen.

In particular example embodiments, augmented reality (AR) is used to aida user in capturing the multiple images used in a MVIDMR. For example, avirtual guide can be inserted into live image data from a mobile. Thevirtual guide can help the user guide the mobile device along adesirable path useful for creating the MVIDMR. The virtual guide in theAR images can respond to movements of the mobile device. The movement ofmobile device can be determined from a number of different sources,including but not limited to an Inertial Measurement Unit and imagedata.

Various aspects also relate generally to systems and methods forproviding feedback when generating a MVIDMR. For example, objectrecognition may be used to recognize an object present in a MVIDMR.Then, feedback such as one or more visual indicators may be provided toguide the user in collecting additional MVIDMR data to collect ahigh-quality MVIDMR of the object. As another example, a target view maybe determined for a MVIDMR, such as the terminal point when capturing a360-degree MVIDMR. Then, feedback such as one or more visual indicatorsmay be provided to guide the user in collecting additional MVIDMR datato reach the target view.

FIG. 24 shows an example of a MVIDMR acquisition system 2400, configuredin accordance with one or more embodiments. The MVIDMR acquisitionsystem 2400 is depicted in a flow sequence that can be used to generatea MVIDMR. According to various embodiments, the data used to generate aMVIDMR can come from a variety of sources.

In particular, data such as, but not limited to two-dimensional (2D)images 2404 can be used to generate a MVIDMR. These 2D images caninclude color image data streams such as multiple image sequences, videodata, etc., or multiple images in any of various formats for images,depending on the application. As will be described in more detail belowwith respect to FIGS. 7A-11B, during an image capture process, an ARsystem can be used. The AR system can receive and augment live imagedata with virtual data. In particular, the virtual data can includeguides for helping a user direct the motion of an image capture device.

Another source of data that can be used to generate a MVIDMR includesenvironment information 2406. This environment information 2406 can beobtained from sources such as accelerometers, gyroscopes, magnetometers,GPS, WiFi, IMU-like systems (Inertial Measurement Unit systems), and thelike. Yet another source of data that can be used to generate a MVIDMRcan include depth images 2408. These depth images can include depth, 3D,or disparity image data streams, and the like, and can be captured bydevices such as, but not limited to, stereo cameras, time-of-flightcameras, three-dimensional cameras, and the like.

In some embodiments, the data can then be fused together at sensorfusion block 2410. In some embodiments, a MVIDMR can be generated acombination of data that includes both 2D images 2404 and environmentinformation 2406, without any depth images 2408 provided. In otherembodiments, depth images 2408 and environment information 2406 can beused together at sensor fusion block 2410. Various combinations of imagedata can be used with environment information at 2406, depending on theapplication and available data.

In some embodiments, the data that has been fused together at sensorfusion block 2410 is then used for content modeling 2412 and contextmodeling 2414. The subject matter featured in the images can beseparated into content and context. The content can be delineated as theobject of interest and the context can be delineated as the scenerysurrounding the object of interest. According to various embodiments,the content can be a three-dimensional model, depicting an object ofinterest, although the content can be a two-dimensional image in someembodiments. Furthermore, in some embodiments, the context can be atwo-dimensional model depicting the scenery surrounding the object ofinterest. Although in many examples the context can providetwo-dimensional views of the scenery surrounding the object of interest,the context can also include three-dimensional aspects in someembodiments. For instance, the context can be depicted as a “flat” imagealong a cylindrical “canvas,” such that the “flat” image appears on thesurface of a cylinder. In addition, some examples may includethree-dimensional context models, such as when some objects areidentified in the surrounding scenery as three-dimensional objects.According to various embodiments, the models provided by contentmodeling 2412 and context modeling 2414 can be generated by combiningthe image and location information data.

According to various embodiments, context and content of a MVIDMR aredetermined based on a specified object of interest. In some embodiments,an object of interest is automatically chosen based on processing of theimage and location information data. For instance, if a dominant objectis detected in a series of images, this object can be selected as thecontent. In other examples, a user specified target 2402 can be chosen,as shown in FIG. 24 . It should be noted, however, that a MVIDMR can begenerated without a user-specified target in some applications.

In some embodiments, one or more enhancement algorithms can be appliedat enhancement algorithm(s) block 2416. In particular exampleembodiments, various algorithms can be employed during capture of MVIDMRdata, regardless of the type of capture mode employed. These algorithmscan be used to enhance the user experience. For instance, automaticframe selection, stabilization, view interpolation, filters, and/orcompression can be used during capture of MVIDMR data. In someembodiments, these enhancement algorithms can be applied to image dataafter acquisition of the data. In other examples, these enhancementalgorithms can be applied to image data during capture of MVIDMR data.

According to various embodiments, automatic frame selection can be usedto create a more enjoyable MVIDMR. Specifically, frames areautomatically selected so that the transition between them will besmoother or more even. This automatic frame selection can incorporateblur- and overexposure-detection in some applications, as well as moreuniformly sampling poses such that they are more evenly distributed.

In some embodiments, stabilization can be used for a MVIDMR in a mannersimilar to that used for video. In particular, keyframes in a MVIDMR canbe stabilized for to produce improvements such as smoother transitions,improved/enhanced focus on the content, etc. However, unlike video,there are many additional sources of stabilization for a MVIDMR, such asby using IMU information, depth information, computer vision techniques,direct selection of an area to be stabilized, face detection, and thelike.

For instance, IMU information can be very helpful for stabilization. Inparticular, IMU information provides an estimate, although sometimes arough or noisy estimate, of the camera tremor that may occur duringimage capture. This estimate can be used to remove, cancel, and/orreduce the effects of such camera tremor.

In some embodiments, depth information, if available, can be used toprovide stabilization for a MVIDMR. Because points of interest in aMVIDMR are three-dimensional, rather than two-dimensional, these pointsof interest are more constrained and tracking/matching of these pointsis simplified as the search space reduces. Furthermore, descriptors forpoints of interest can use both color and depth information andtherefore, become more discriminative. In addition, automatic orsemi-automatic content selection can be easier to provide with depthinformation. For instance, when a user selects a particular pixel of animage, this selection can be expanded to fill the entire surface thattouches it. Furthermore, content can also be selected automatically byusing a foreground/background differentiation based on depth. Accordingto various embodiments, the content can stay relatively stable/visibleeven when the context changes.

According to various embodiments, computer vision techniques can also beused to provide stabilization for MVIDMRs. For instance, keypoints canbe detected and tracked. However, in certain scenes, such as a dynamicscene or static scene with parallax, no simple warp exists that canstabilize everything. Consequently, there is a trade-off in whichcertain aspects of the scene receive more attention to stabilization andother aspects of the scene receive less attention. Because a MVIDMR isoften focused on a particular object of interest, a MVIDMR can becontent-weighted so that the object of interest is maximally stabilizedin some examples.

Another way to improve stabilization in a MVIDMR includes directselection of a region of a screen. For instance, if a user taps to focuson a region of a screen, then records a convex MVIDMR, the area that wastapped can be maximally stabilized. This allows stabilization algorithmsto be focused on a particular area or object of interest.

In some embodiments, face detection can be used to providestabilization. For instance, when recording with a front-facing camera,it is often likely that the user is the object of interest in the scene.Thus, face detection can be used to weight stabilization about thatregion. When face detection is precise enough, facial featuresthemselves (such as eyes, nose, and mouth) can be used as areas tostabilize, rather than using generic keypoints. In another example, auser can select an area of image to use as a source for keypoints.

According to various embodiments, view interpolation can be used toimprove the viewing experience. In particular, to avoid sudden “jumps”between stabilized frames, synthetic, intermediate views can be renderedon the fly. This can be informed by content-weighted keypoint tracks andIMU information as described above, as well as by denser pixel-to-pixelmatches. If depth information is available, fewer artifacts resultingfrom mismatched pixels may occur, thereby simplifying the process. Asdescribed above, view interpolation can be applied during capture of aMVIDMR in some embodiments. In other embodiments, view interpolation canbe applied during MVIDMR generation.

In some embodiments, filters can also be used during capture orgeneration of a MVIDMR to enhance the viewing experience. Just as manypopular photo sharing services provide aesthetic filters that can beapplied to static, two-dimensional images, aesthetic filters cansimilarly be applied to surround images. However, because a MVIDMRrepresentation is more expressive than a two-dimensional image, andthree-dimensional information is available in a MVIDMR, these filterscan be extended to include effects that are ill-defined in twodimensional photos. For instance, in a MVIDMR, motion blur can be addedto the background (i.e. context) while the content remains crisp. Inanother example, a drop-shadow can be added to the object of interest ina MVIDMR.

According to various embodiments, compression can also be used as anenhancement algorithm 2416. In particular, compression can be used toenhance user-experience by reducing data upload and download costs.Because MVIDMRs use spatial information, far less data can be sent for aMVIDMR than a typical video, while maintaining desired qualities of theMVIDMR. Specifically, the IMU, keypoint tracks, and user input, combinedwith the view interpolation described above, can all reduce the amountof data that must be transferred to and from a device during upload ordownload of a MVIDMR. For instance, if an object of interest can beproperly identified, a variable compression style can be chosen for thecontent and context. This variable compression style can include lowerquality resolution for background information (i.e. context) and higherquality resolution for foreground information (i.e. content) in someexamples. In such examples, the amount of data transmitted can bereduced by sacrificing some of the context quality, while maintaining adesired level of quality for the content.

In the present embodiment, a MVIDMR 2418 is generated after anyenhancement algorithms are applied. The MVIDMR can provide a multi-viewinteractive digital media representation. According to variousembodiments, the MVIDMR can include three-dimensional model of thecontent and a two-dimensional model of the context. However, in someexamples, the context can represent a “flat” view of the scenery orbackground as projected along a surface, such as a cylindrical orother-shaped surface, such that the context is not purelytwo-dimensional. In yet other examples, the context can includethree-dimensional aspects.

According to various embodiments, MVIDMRs provide numerous advantagesover traditional two-dimensional images or videos. Some of theseadvantages include: the ability to cope with moving scenery, a movingacquisition device, or both; the ability to model parts of the scene inthree-dimensions; the ability to remove unnecessary, redundantinformation and reduce the memory footprint of the output dataset; theability to distinguish between content and context; the ability to usethe distinction between content and context for improvements in theuser-experience; the ability to use the distinction between content andcontext for improvements in memory footprint (an example would be highquality compression of content and low quality compression of context);the ability to associate special feature descriptors with MVIDMRs thatallow the MVIDMRs to be indexed with a high degree of efficiency andaccuracy; and the ability of the user to interact and change theviewpoint of the MVIDMR. In particular example embodiments, thecharacteristics described above can be incorporated natively in theMVIDMR representation, and provide the capability for use in variousapplications. For instance, MVIDMRs can be used to enhance variousfields such as e-commerce, visual search, 3D printing, file sharing,user interaction, and entertainment.

According to various example embodiments, once a MVIDMR 2418 isgenerated, user feedback for acquisition 2420 of additional image datacan be provided. In particular, if a MVIDMR is determined to needadditional views to provide a more accurate model of the content orcontext, a user may be prompted to provide additional views. Once theseadditional views are received by the MVIDMR acquisition system 2400,these additional views can be processed by the system 2400 andincorporated into the MVIDMR.

FIG. 25 shows an example of a process flow diagram for generating aMVIDMR 2500. In the present example, a plurality of images is obtainedat 2502. According to various embodiments, the plurality of images caninclude two-dimensional (2D) images or data streams. These 2D images caninclude location information that can be used to generate a MVIDMR. Insome embodiments, the plurality of images can include depth images. Thedepth images can also include location information in various examples.

In some embodiments, when the plurality of images is captured, imagesoutput to the user can be augmented with the virtual data. For example,the plurality of images can be captured using a camera system on amobile device. The live image data, which is output to a display on themobile device, can include virtual data, such as guides and statusindicators, rendered into the live image data. The guides can help auser guide a motion of the mobile device. The status indicators canindicate what portion of images needed for generating a MVIDMR have beencaptured. The virtual data may not be included in the image datacaptured for the purposes of generating the MVIDMR.

According to various embodiments, the plurality of images obtained at2502 can include a variety of sources and characteristics. For instance,the plurality of images can be obtained from a plurality of users. Theseimages can be a collection of images gathered from the internet fromdifferent users of the same event, such as 2D images or video obtainedat a concert, etc. In some embodiments, the plurality of images caninclude images with different temporal information. In particular, theimages can be taken at different times of the same object of interest.For instance, multiple images of a particular statue can be obtained atdifferent times of day, different seasons, etc. In other examples, theplurality of images can represent moving objects. For instance, theimages may include an object of interest moving through scenery, such asa vehicle traveling along a road or a plane traveling through the sky.In other instances, the images may include an object of interest that isalso moving, such as a person dancing, running, twirling, etc.

In some embodiments, the plurality of images is fused into content andcontext models at 2504. According to various embodiments, the subjectmatter featured in the images can be separated into content and context.The content can be delineated as the object of interest and the contextcan be delineated as the scenery surrounding the object of interest.According to various embodiments, the content can be a three-dimensionalmodel, depicting an object of interest, and the content can be atwo-dimensional image in some embodiments.

According to the present example embodiment, one or more enhancementalgorithms can be applied to the content and context models at 2506.These algorithms can be used to enhance the user experience. Forinstance, enhancement algorithms such as automatic frame selection,stabilization, view interpolation, filters, and/or compression can beused. In some embodiments, these enhancement algorithms can be appliedto image data during capture of the images. In other examples, theseenhancement algorithms can be applied to image data after acquisition ofthe data.

In the present embodiment, a MVIDMR is generated from the content andcontext models at 2508. The MVIDMR can provide a multi-view interactivedigital media representation. According to various embodiments, theMVIDMR can include a three-dimensional model of the content and atwo-dimensional model of the context. According to various embodiments,depending on the mode of capture and the viewpoints of the images, theMVIDMR model can include certain characteristics. For instance, someexamples of different styles of MVIDMRs include a locally concaveMVIDMR, a locally convex MVIDMR, and a locally flat MVIDMR. However, itshould be noted that MVIDMRs can include combinations of views andcharacteristics, depending on the application.

FIG. 26 shows an example of multiple camera views that can be fusedtogether into a three-dimensional (3D) model to create an immersiveexperience. According to various embodiments, multiple images can becaptured from various viewpoints and fused together to provide a MVIDMR.In some embodiments, three cameras 2612, 2614, and 2616 are positionedat locations 2622, 2624, and 2626, respectively, in proximity to anobject of interest 2608. Scenery can surround the object of interest2608 such as object 2610. Views 2602, 2604, and 2606 from theirrespective cameras 2612, 2614, and 2616 include overlapping subjectmatter. Specifically, each view 2602, 2604, and 2606 includes the objectof interest 2608 and varying degrees of visibility of the scenerysurrounding the object 2610. For instance, view 2602 includes a view ofthe object of interest 2608 in front of the cylinder that is part of thescenery surrounding the object 2610. View 2606 shows the object ofinterest 2608 to one side of the cylinder, and view 2604 shows theobject of interest without any view of the cylinder.

In some embodiments, the various views 2602, 2604, and 2616 along withtheir associated locations 2622, 2624, and 2626, respectively, provide arich source of information about object of interest 2608 and thesurrounding context that can be used to produce a MVIDMR. For instance,when analyzed together, the various views 2602, 2604, and 2626 provideinformation about different sides of the object of interest and therelationship between the object of interest and the scenery. Accordingto various embodiments, this information can be used to parse out theobject of interest 2608 into content and the scenery as the context.Furthermore, various algorithms can be applied to images produced bythese viewpoints to create an immersive, interactive experience whenviewing a MVIDMR.

FIG. 27 illustrates one example of separation of content and context ina MVIDMR. According to various embodiments, a MVIDMR is a multi-viewinteractive digital media representation of a scene 2700. With referenceto FIG. 27 , shown is a user 2702 located in a scene 2700. The user 2702is capturing images of an object of interest, such as a statue. Theimages captured by the user constitute digital visual data that can beused to generate a MVIDMR.

According to various embodiments of the present disclosure, the digitalvisual data included in a MVIDMR can be, semantically and/orpractically, separated into content 2704 and context 2706. According toparticular embodiments, content 2704 can include the object(s),person(s), or scene(s) of interest while the context 2706 represents theremaining elements of the scene surrounding the content 2704. In someembodiments, a MVIDMR may represent the content 2704 asthree-dimensional data, and the context 2706 as a two-dimensionalpanoramic background. In other examples, a MVIDMR may represent both thecontent 2704 and context 2706 as two-dimensional panoramic scenes. Inyet other examples, content 2704 and context 2706 may includethree-dimensional components or aspects. In particular embodiments, theway that the MVIDMR depicts content 2704 and context 2706 depends on thecapture mode used to acquire the images.

In some embodiments, such as but not limited to: recordings of objects,persons, or parts of objects or persons, where only the object, person,or parts of them are visible, recordings of large flat areas, andrecordings of scenes where the data captured appears to be at infinity(i.e., there are no subjects close to the camera), the content 2704 andthe context 2706 may be the same. In these examples, the MVIDMR producedmay have some characteristics that are similar to other types of digitalmedia such as panoramas. However, according to various embodiments,MVIDMRs include additional features that distinguish them from theseexisting types of digital media. For instance, a MVIDMR can representmoving data. Additionally, a MVIDMR is not limited to a specificcylindrical, spherical or translational movement. Various motions can beused to capture image data with a camera or other capture device.Furthermore, unlike a stitched panorama, a MVIDMR can display differentsides of the same object.

FIGS. 28A-28B illustrate examples of concave and convex views,respectively, where both views use a back-camera capture style. Inparticular, if a camera phone is used, these views use the camera on theback of the phone, facing away from the user. In particular embodiments,concave and convex views can affect how the content and context aredesignated in a MVIDMR.

With reference to FIG. 28A, shown is one example of a concave view 2800in which a user is standing along a vertical axis 2808. In this example,the user is holding a camera, such that camera location 2802 does notleave axis 2808 during image capture. However, as the user pivots aboutaxis 2808, the camera captures a panoramic view of the scene around theuser, forming a concave view. In this embodiment, the object of interest2804 and the distant scenery 2806 are all viewed similarly because ofthe way in which the images are captured. In this example, all objectsin the concave view appear at infinity, so the content is equal to thecontext according to this view.

With reference to FIG. 28B, shown is one example of a convex view 2820in which a user changes position when capturing images of an object ofinterest 2824. In this example, the user moves around the object ofinterest 2824, taking pictures from different sides of the object ofinterest from camera locations 2828, 2830, and 2832. Each of the imagesobtained includes a view of the object of interest, and a background ofthe distant scenery 2826. In the present example, the object of interest2824 represents the content, and the distant scenery 2826 represents thecontext in this convex view.

FIGS. 29A-30B illustrate examples of various capture modes for MVIDMRs.Although various motions can be used to capture a MVIDMR and are notconstrained to any particular type of motion, three general types ofmotion can be used to capture particular features or views described inconjunction MVIDMRs. These three types of motion, respectively, canyield a locally concave MVIDMR, a locally convex MVIDMR, and a locallyflat MVIDMR. In some embodiments, a MVIDMR can include various types ofmotions within the same MVIDMR.

With reference to FIG. 29A, shown is an example of a back-facing,concave MVIDMR being captured. According to various embodiments, alocally concave MVIDMR is one in which the viewing angles of the cameraor other capture device diverge. In one dimension this can be likened tothe motion required to capture a spherical 360 panorama (pure rotation),although the motion can be generalized to any curved sweeping motion inwhich the view faces outward. In the present example, the experience isthat of a stationary viewer looking out at a (possibly dynamic) context.

In some embodiments, a user 2902 is using a back-facing camera 2906 tocapture images towards world 2900, and away from user 2902. As describedin various examples, a back-facing camera refers to a device with acamera that faces away from the user, such as the camera on the back ofa smart phone. The camera is moved in a concave motion 2908, such thatviews 2904 a, 2904 b, and 2904 c capture various parts of capture area2909.

With reference to FIG. 29B, shown is an example of a back-facing, convexMVIDMR being captured. According to various embodiments, a locallyconvex MVIDMR is one in which viewing angles converge toward a singleobject of interest. In some embodiments, a locally convex MVIDMR canprovide the experience of orbiting about a point, such that a viewer cansee multiple sides of the same object. This object, which may be an“object of interest,” can be segmented from the MVIDMR to become thecontent, and any surrounding data can be segmented to become thecontext. Previous technologies fail to recognize this type of viewingangle in the media-sharing landscape.

In some embodiments, a user 2902 is using a back-facing camera 2914 tocapture images towards world 2900, and away from user 2902. The camerais moved in a convex motion 2910, such that views 2912 a, 2912 b, and2912 c capture various parts of capture area 2911. As described above,world 2900 can include an object of interest in some examples, and theconvex motion 2910 can orbit around this object. Views 2912 a, 2912 b,and 2912 c can include views of different sides of this object in theseexamples.

With reference to FIG. 30A, shown is an example of a front-facing,concave MVIDMR being captured. As described in various examples, afront-facing camera refers to a device with a camera that faces towardsthe user, such as the camera on the front of a smart phone. Forinstance, front-facing cameras are commonly used to take “selfies”(i.e., self-portraits of the user).

In some embodiments, camera 3020 is facing user 3002. The camera followsa concave motion 3006 such that the views 3018 a, 3018 b, and 3018 cdiverge from each other in an angular sense. The capture area 3017follows a concave shape that includes the user at a perimeter.

With reference to FIG. 30B, shown is an example of a front-facing,convex MVIDMR being captured. In some embodiments, camera 3026 is facinguser 3002. The camera follows a convex motion 3022 such that the views3024 a, 3024 b, and 3024 c converge towards the user 3002. As describedabove, various modes can be used to capture images for a MVIDMR. Thesemodes, including locally concave, locally convex, and locally linearmotions, can be used during capture of separate images or duringcontinuous recording of a scene. Such recording can capture a series ofimages during a single session.

In some embodiments, the augmented reality system can be implemented ona mobile device, such as a cell phone. In particular, the live cameradata, which is output to a display on the mobile device, can beaugmented with virtual objects. The virtual objects can be rendered intothe live camera data. In some embodiments, the virtual objects canprovide a user feedback when images are being captured for a MVIDMR.

FIGS. 31 and 32 illustrate an example of a process flow for capturingimages in a MVIDMR using augmented reality. In 3102, live image data canbe received from a camera system. For example, live image data can bereceived from one or more cameras on a handheld mobile device, such as asmartphone. The image data can include pixel data captured from a camerasensor. The pixel data varies from frame to frame. In some embodiments,the pixel data can be 2-D. In other embodiments, depth data can beincluded with the pixel data.

In 3104, sensor data can be received. For example, the mobile device caninclude an IMU with accelerometers and gyroscopes. The sensor data canbe used to determine an orientation of the mobile device, such as a tiltorientation of the device relative to the gravity vector. Thus, theorientation of the live 2-D image data relative to the gravity vectorcan also be determined. In addition, when the user applied accelerationscan be separated from the acceleration due to gravity, it may bepossible to determine changes in position of the mobile device as afunction of time.

In particular embodiments, a camera reference frame can be determined.In the camera reference frame, one axis is aligned with a lineperpendicular to the camera lens. Using an accelerometer on the phone,the camera reference frame can be related to an Earth reference frame.The earth reference frame can provide a 3-D coordinate system where oneof the axes is aligned with the Earths' gravitational vector. Therelationship between the camera frame and Earth reference frame can beindicated as yaw, roll and tilt/pitch. Typically, at least two of thethree of yaw, roll and pitch are available typically from sensorsavailable on a mobile device, such as smart phone's gyroscopes andaccelerometers.

The combination of yaw-roll-tilt information from the sensors, such as asmart phone or tablets accelerometers and the data from the cameraincluding the pixel data can be used to relate the 2-D pixel arrangementin the camera field of view to the 3-D reference frame in the realworld. In some embodiments, the 2-D pixel data for each picture can betranslated to a reference frame as if the camera where resting on ahorizontal plane perpendicular to an axis through the gravitationalcenter of the Earth where a line drawn through the center of lensperpendicular to the surface of lens is mapped to a center of the pixeldata. This reference frame can be referred as an Earth reference frame.Using this calibration of the pixel data, a curve or object defined in3-D space in the earth reference frame can be mapped to a planeassociated with the pixel data (2-D pixel data). If depth data isavailable, i.e., the distance of the camera to a pixel. Then, thisinformation can also be utilized in a transformation.

In alternate embodiments, the 3-D reference frame in which an object isdefined doesn't have to be an Earth reference frame. In someembodiments, a 3-D reference in which an object is drawn and thenrendered into the 2-D pixel frame of reference can be defined relativeto the Earth reference frame. In another embodiment, a 3-D referenceframe can be defined relative to an object or surface identified in thepixel data and then the pixel data can be calibrated to this 3-Dreference frame.

As an example, the object or surface can be defined by a number oftracking points identified in the pixel data. Then, as the camera moves,using the sensor data and a new position of the tracking points, achange in the orientation of the 3-D reference frame can be determinedfrom frame to frame. This information can be used to render virtual datain a live image data and/or virtual data into a MVIDMR.

Returning to FIG. 31 , in 3106, virtual data associated with a targetcan be generated in the live image data. For example, the target can becross hairs. In general, the target can be rendered as any shape orcombinations of shapes. In some embodiments, via an input interface, auser may be able to adjust a position of the target. For example, usinga touch screen over a display on which the live image data is output,the user may be able to place the target at a particular location in thesynthetic image. The synthetic image can include a combination of liveimage data rendered with one or more virtual objects.

For example, the target can be placed over an object that appears in theimage, such as a face or a person. Then, the user can provide anadditional input via an interface that indicates the target is in adesired location. For example, the user can tap the touch screenproximate to the location where the target appears on the display. Then,an object in the image below the target can be selected. As anotherexample, a microphone in the interface can be used to receive voicecommands which direct a position of the target in the image (e.g., moveleft, move right, etc.) and then confirm when the target is in a desiredlocation (e.g., select target).

In some instances, object recognition can be available. Objectrecognition can identify possible objects in the image. Then, the liveimages can be augmented with a number of indicators, such as targets,which mark identified objects. For example, objects, such as people,parts of people (e.g., faces), cars, wheels, can be marked in the image.Via an interface, the person may be able to select one of the markedobjects, such as via the touch screen interface. In another embodiment,the person may be able to provide a voice command to select an object.For example, the person may be to say something like “select face,” or“select car.”

In 3108, the object selection can be received. The object selection canbe used to determine an area within the image data to identify trackingpoints. When the area in the image data is over a target, the trackingpoints can be associated with an object appearing in the live imagedata.

In 3110, tracking points can be identified which are related to theselected object. Once an object is selected, the tracking points on theobject can be identified on a frame to frame basis. Thus, if the cameratranslates or changes orientation, the location of the tracking pointsin the new frame can be identified and the target can be rendered in thelive images so that it appears to stay over the tracked object in theimage. This feature is discussed in more detail below. In particularembodiments, object detection and/or recognition may be used for each ormost frames, for instance to facilitate identifying the location oftracking points.

In some embodiments, tracking an object can refer to tracking one ormore points from frame to frame in the 2-D image space. The one or morepoints can be associated with a region in the image. The one or morepoints or regions can be associated with an object. However, the objectdoesn't have to be identified in the image. For example, the boundariesof the object in 2-D image space don't have to be known. Further, thetype of object doesn't have to be identified. For example, adetermination doesn't have to be made as to whether the object is a car,a person or something else appearing in the pixel data. Instead, the oneor more points may be tracked based on other image characteristics thatappear in successive frames. For instance, edge tracking, cornertracking, or shape tracking may be used to track one or more points fromframe to frame.

One advantage of tracking objects in the manner described in the 2-Dimage space is that a 3-D reconstruction of an object or objectsappearing in an image don't have to be performed. The 3-D reconstructionstep may involve operations such as “structure from motion (SFM)” and/or“simultaneous localization and mapping (SLAM).” The 3-D reconstructioncan involve measuring points in multiple images, and the optimizing forthe camera poses and the point locations. When this process is avoided,significant computation time is saved. For example, avoiding theSLAM/SFM computations can enable the methods to be applied when objectsin the images are moving. Typically, SLAM/SFM computations assume staticenvironments.

In 3112, a 3-D coordinate system in the physical world can be associatedwith the image, such as the Earth reference frame, which as describedabove can be related to camera reference frame associated with the 2-Dpixel data. In some embodiments, the 2-D image data can be calibrated sothat the associated 3-D coordinate system is anchored to the selectedtarget such that the target is at the origin of the 3-D coordinatesystem.

Then, in 3114, a 2-D or 3-D trajectory or path can be defined in the 3-Dcoordinate system. For example, a trajectory or path, such as an arc ora parabola can be mapped to a drawing plane which is perpendicular tothe gravity vector in the Earth reference frame. As described above,based upon the orientation of the camera, such as information providedfrom an IMU, the camera reference frame including the 2-D pixel data canbe mapped to the Earth reference frame. The mapping can be used torender the curve defined in the 3-D coordinate system into the 2-D pixeldata from the live image data. Then, a synthetic image including thelive image data and the virtual object, which is the trajectory or path,can be output to a display.

In general, virtual objects, such as curves or surfaces can be definedin a 3-D coordinate system, such as the Earth reference frame or someother coordinate system related to an orientation of the camera. Then,the virtual objects can be rendered into the 2-D pixel data associatedwith the live image data to create a synthetic image. The syntheticimage can be output to a display.

In some embodiments, the curves or surfaces can be associated with a 3-Dmodel of an object, such as person or a car. In another embodiment, thecurves or surfaces can be associated with text. Thus, a text message canbe rendered into the live image data. In other embodiments, textures canbe assigned to the surfaces in the 3-D model. When a synthetic image iscreated, these textures can be rendered into the 2-D pixel dataassociated with the live image data.

When a curve is rendered on a drawing plane in the 3-D coordinatesystem, such as the Earth reference frame, one or more of the determinedtracking points can be projected onto the drawing plane. As anotherexample, a centroid associated with the tracked points can be projectedonto the drawing plane. Then, the curve can be defined relative to oneor more points projected onto the drawing plane. For example, based uponthe target location, a point can be determined on the drawing plane.Then, the point can be used as the center of a circle or arc of someradius drawn in the drawing plane.

In 3114, based upon the associated coordinate system, a curve can berendered into to the live image data as part of the AR system. Ingeneral, one or more virtual objects including plurality of curves,lines or surfaces can be rendered into the live image data. Then, thesynthetic image including the live image data and the virtual objectscan be output to a display in real-time.

In some embodiments, the one or more virtual object rendered into thelive image data can be used to help a user capture images used to createa MVIDMR. For example, the user can indicate a desire to create a MVIDMRof a real object identified in the live image data. The desired MVIDMRcan span some angle range, such as forty-five, ninety, one hundredeighty degrees or three hundred sixty degrees. Then, a virtual objectcan be rendered as a guide where the guide is inserted into the liveimage data. The guide can indicate a path along which to move the cameraand the progress along the path. The insertion of the guide can involvemodifying the pixel data in the live image data in accordance withcoordinate system in 3112.

In the example above, the real object can be some object which appearsin the live image data. For the real object, a 3-D model may not beconstructed. Instead, pixel locations or pixel areas can be associatedwith the real object in the 2-D pixel data. This definition of the realobject is much less computational expensive than attempting to constructa 3-D model of the real object in physical space.

The virtual objects, such as lines or surfaces can be modeled in the 3-Dspace. The virtual objects can be defined a priori. Thus, the shape ofthe virtual object doesn't have to be constructed in real-time, which iscomputational expensive. The real objects which may appear in an imageare not known a priori. Hence, 3-D models of the real object are nottypically available. Therefore, the synthetic image can include “real”objects which are only defined in the 2-D image space via assigningtracking points or areas to the real object and virtual objects whichare modeled in a 3-D coordinate system and then rendered into the liveimage data.

Returning to FIG. 31 , in 3116, AR image with one or more virtualobjects can be output. The pixel data in the live image data can bereceived at a particular frame rate. In particular embodiments, theaugmented frames can be output at the same frame rate as it received. Inother embodiments, it can be output at a reduced frame rate. The reducedframe rate can lessen computation requirements. For example, live datareceived at 30 frames per second can be output at 15 frames per second.In another embodiment, the AR images can be output at a reducedresolution, such as 240 p instead of 480p. The reduced resolution canalso be used to reduce computational requirements.

In 3118, one or more images can be selected from the live image data andstored for use in a MVIDMR. In some embodiments, the stored images caninclude one or more virtual objects. Thus, the virtual objects can bebecome part of the MVIDMR. In other embodiments, the virtual objects areonly output as part of the AR system. But, the image data which isstored for use in the MVIDMR may not include the virtual objects.

In yet other embodiments, a portion of the virtual objects output to thedisplay as part of the AR system can be stored. For example, the ARsystem can be used to render a guide during the MVIDMR image captureprocess and render a label associated with the MVIDMR. The label may bestored in the image data for the MVIDMR. However, the guide may not bestored. To store the images without the added virtual objects, a copymay have to be made. The copy can be modified with the virtual data andthen output to a display and the original stored or the original can bestored prior to its modification.

In FIG. 32 , the method in FIG. 31 is continued. In 3222, new image datacan be received. In 3224, new IMU data (or, in general sensor data) canbe received. The IMU data can represent a current orientation of thecamera. In 3226, the location of the tracking points identified inprevious image data can be identified in the new image data.

The camera may have tilted and/or moved. Hence, the tracking points mayappear at a different location in the pixel data. As described above,the tracking points can be used to define a real object appearing in thelive image data. Thus, identifying the location of the tracking pointsin the new image data allows the real object to be tracked from image toimage. The differences in IMU data from frame to frame and knowledge ofthe rate at which the frames are recorded can be used to help todetermine a change in location of tracking points in the live image datafrom frame to frame.

The tracking points associated with a real object appearing in the liveimage data may change over time. As a camera moves around the realobject, some tracking points identified on the real object may go out ofview as new portions of the real object come into view and otherportions of the real object are occluded. Thus, in 3226, a determinationmay be made whether a tracking point is still visible in an image. Inaddition, a determination may be made as to whether a new portion of thetargeted object has come into view. New tracking points can be added tothe new portion to allow for continued tracking of the real object fromframe to frame.

In 3228, a coordinate system can be associated with the image. Forexample, using an orientation of the camera determined from the sensordata, the pixel data can be calibrated to an Earth reference frame aspreviously described. In 3230, based upon the tracking points currentlyplaced on the object and the coordinate system a target location can bedetermined. The target can be placed over the real object which istracked in live image data. As described above, a number and a locationof the tracking points identified in an image can vary with time as theposition of the camera changes relative to the camera. Thus, thelocation of the target in the 2-D pixel data can change. A virtualobject representing the target can be rendered into the live image data.In particular embodiments, a coordinate system may be defined based onidentifying a position from the tracking data and an orientation fromthe IMU (or other) data.

In 3232, a track location in the live image data can be determined. Thetrack can be used to provide feedback associated with a position andorientation of a camera in physical space during the image captureprocess for a MVIDMR. As an example, as described above, the track canbe rendered in a drawing plane which is perpendicular to the gravityvector, such as parallel to the ground. Further, the track can berendered relative to a position of the target, which is a virtualobject, placed over a real object appearing in the live image data.Thus, the track can appear to surround or partially surround the object.As described above, the position of the target can be determined fromthe current set of tracking points associated with the real objectappearing in the image. The position of the target can be projected ontothe selected drawing plane.

In 3234, a capture indicator status can be determined. The captureindicator can be used to provide feedback in regards to what portion ofthe image data used in a MVIDMR has been captured. For example, thestatus indicator may indicate that half of angle range of images for usein a MVIDMR has been captured. In another embodiment, the statusindicator may be used to provide feedback in regards to whether thecamera is following a desired path and maintaining a desired orientationin physical space. Thus, the status indicator may indicate the currentpath or orientation of the camera is desirable or not desirable. Whenthe current path or orientation of the camera is not desirable, thestatus indicator may be configured to indicate what type of correctionwhich is needed, such as but not limited to moving the camera moreslowly, starting the capture process over, tilting the camera in acertain direction and/or translating the camera in a particulardirection.

In 3236, a capture indicator location can be determined. The locationcan be used to render the capture indicator into the live image andgenerate the synthetic image. In some embodiments, the position of thecapture indicator can be determined relative to a position of the realobject in the image as indicated by the current set of tracking points,such as above and to left of the real object. In 3238, a syntheticimage, i.e., a live image augmented with virtual objects, can begenerated. The synthetic image can include the target, the track and oneor more status indicators at their determined locations, respectively.In 3240, image data captured for the purposes of use in a MVIDMR can becaptured. As described above, the stored image data can be raw imagedata without virtual objects or may include virtual objects.

In 3242, a check can be made as to whether images needed to generate aMVIDMR have been captured in accordance with the selected parameters,such as a MVIDMR spanning a desired angle range. When the capture is notcomplete, new image data may be received and the method may return to3222. When the capture is complete, a virtual object can be renderedinto the live image data indicating the completion of the captureprocess for the MVIDMR and a MVIDMR can be created. Some virtual objectsassociated with the capture process may cease to be rendered. Forexample, once the needed images have been captured the track used tohelp guide the camera during the capture process may no longer begenerated in the live image data.

FIGS. 33A and 33B illustrate aspects of generating an Augmented Reality(AR) image capture track for capturing images used in a MVIDMR. In FIG.33A, a mobile device 3314 with a display 3316 is shown. The mobiledevice can include at least one camera (not shown) with a field of view3300. A real object 3302, which is a person, is selected in the field ofview 3300 of the camera. A virtual object, which is a target (notshown), may have been used to help select the real object. For example,the target on a touch screen display of the mobile device 3314 may havebeen placed over the object 3302 and then selected.

The camera can include an image sensor which captures light in the fieldof view 3300. The data from the image sensor can be converted to pixeldata. The pixel data can be modified prior to its output on display 3316to generate a synthetic image. The modifications can include renderingvirtual objects in the pixel data as part of an augmented reality (AR)system.

Using the pixel data and a selection of the object 3302, tracking pointson the object can be determined. The tracking points can define theobject in image space. Locations of a current set of tracking points,such as 3305, 3306 and 3308, which can be attached to the object 3302are shown. As a position and orientation of the camera on the mobiledevice 3314, the shape and position of the object 3302 in the capturedpixel data can change. Thus, the location of the tracking points in thepixel data can change. Thus, a previously defined tracking point canmove from a first location in the image data to a second location. Also,a tracking point can disappear from the image as portions of the objectare occluded.

Using sensor data from the mobile device 3314, an Earth reference frame3-D coordinate system 3304 can be associated with the image data. Thedirection of the gravity vector is indicated by arrow 3310. As describedabove, in a particular embodiment, the 2-D image data can be calibratedrelative to the Earth reference frame. The arrow representing thegravity vector is not rendered into the live image data. However, ifdesired, an indicator representative of the gravity could be renderedinto the synthetic image.

A plane which is perpendicular to the gravity vector can be determined.The location of the plane can be determined using the tracking points inthe image, such as 3305, 3306 and 3308. Using this information, a curve,which is a circle, is drawn in the plane. The circle can be renderedinto to the 2-D image data and output as part of the AR system. As isshown on display 3316, the circle appears to surround the object 3302.In some embodiments, the circle can be used as a guide for capturingimages used in a MVIDMR.

If the camera on the mobile device 3314 is rotated in some way, such astilted, the shape of the object will change on display 3316. However,the new orientation of the camera can be determined in space including adirection of the gravity vector. Hence, a plane perpendicular to thegravity vector can be determined. The position of the plane and hence, aposition of the curve in the image can be based upon a centroid of theobject determined from the tracking points associated with the object3302. Thus, the curve can appear to remain parallel to the ground, i.e.,perpendicular to the gravity vector, as the camera 3314 moves. However,the position of the curve can move from location to location in theimage as the position of the object and its apparent shape in the liveimages changes.

In FIG. 33B, a mobile device 3334 including a camera (not shown) and adisplay 3336 for outputting the image data from the camera is shown. Acup 3322 is shown in the field of view of camera 3320 of the camera.Tracking points, such as 3324 and 3326, have been associated with theobject 3322. These tracking points can define the object 3322 in imagespace. Using the IMU data from the mobile device 3334, a reference framehas been associated with the image data. As described above, In someembodiments, the pixel data can be calibrated to the reference frame.The reference frame is indicated by the 3-D axes 3324 and the directionof the gravity vector is indicated by arrow 3328.

As described above, a plane relative to the reference frame can bedetermined. In this example, the plane is parallel to the direction ofthe axis associated with the gravity vector as opposed to perpendicularto the frame. This plane is used to proscribe a path for the MVIDMRwhich goes over the top of the object 3330. In general, any plane can bedetermined in the reference frame and then a curve, which is used as aguide, can be rendered into the selected plane.

Using the locations of the tracking points, in some embodiments acentroid of the object 3322 on the selected plane in the reference canbe determined. A curve 3330, such as a circle, can be rendered relativeto the centroid. In this example, a circle is rendered around the object3322 in the selected plane.

The curve 3330 can serve as a track for guiding the camera along aparticular path where the images captured along the path can beconverted into a MVIDMR. In some embodiments, a position of the cameraalong the path can be determined. Then, an indicator can be generatedwhich indicates a current location of the camera along the path. In thisexample, current location is indicated by arrow 3332.

The position of the camera along the path may not directly map tophysical space, i.e., the actual position of the camera in physicalspace doesn't have to be necessarily determined. For example, an angularchange can be estimated from the IMU data and optionally the frame rateof the camera. The angular change can be mapped to a distance movedalong the curve where the ratio of the distance moved along the path3330 is not a one to one ratio with the distance moved in physicalspace. In another example, a total time to traverse the path 3330 can beestimated and then the length of time during which images have beenrecorded can be tracked. The ratio of the recording time to the totaltime can be used to indicate progress along the path 3330.

The path 3330, which is an arc, and arrow 3332 are rendered into thelive image data as virtual objects in accordance with their positions inthe 3-D coordinate system associated with the live 2-D image data. Thecup 3322, the circle 3330 and the arrow 3332 are shown output to display3336. The orientation of the curve 3330 and the arrow 3332 shown ondisplay 3336 relative to the cup 3322 can change if the orientation ofthe camera is changed, such as if the camera is tilted.

In particular embodiments, a size of the object 3322 in the image datacan be changed. For example, the size of the object can be made biggeror smaller by using a digital zoom. In another example, the size of theobject can be made bigger or smaller by moving the camera, such as onmobile device 3334, closer or farther away from the object 3322.

When the size of the object changes, the distances between the trackingpoints can change, i.e., the pixel distances between the tracking pointscan increase or can decrease. The distance changes can be used toprovide a scaling factor. In some embodiments, as the size of the objectchanges, the AR system can be configured to scale a size of the curve3330 and/or arrow 3332. Thus, a size of the curve relative to the objectcan be maintained.

In another embodiment, a size of the curve can remain fixed. Forexample, a diameter of the curve can be related to a pixel height orwidth of the image, such as 330 percent of the pixel height or width.Thus, the object 3322 can appear to grow or shrink as a zoom is used ora position of the camera is changed. However, the size of curve 3330 inthe image can remain relatively fixed.

FIG. 34 illustrates a second example of generating an Augmented Reality(AR) image capture track for capturing images used in a MVIDMR on amobile device. FIG. 34 includes a mobile device at three times 3400 a,3400 b and 3400 c. The device can include at least one camera, adisplay, an IMU, a processor (CPU), memory, microphone, audio outputdevices, communication interfaces, a power supply, graphic processor(GPU), graphical memory and combinations thereof. The display is shownwith images at three times 3406 a, 3406 b and 3406 c. The display can beoverlaid with a touch screen.

In 3406 a, an image of an object 3408 is output to the display in state3406 a. The object is a rectangular box. The image data output to thedisplay can be live image data from a camera on the mobile device. Thecamera could also be a remote camera.

In some embodiments, a target, such as 3410, can be rendered to thedisplay. The target can be combined with the live image data to create asynthetic image. Via the input interface on the phone, a user may beable to adjust a position of the target on the display. The target canbe placed on an object and then an additional input can be made toselect the object. For example, the touch screen can be tapped at thelocation of the target.

In another embodiment, object recognition can be applied to the liveimage data. Various markers can be rendered to the display, whichindicate the position of the identified objects in the live image data.To select an object, the touchscreen can be tapped at a location of oneof markers appearing in the image or another input device can be used toselect the recognized object.

After an object is selected, a number of initial tracking points can beidentified on the object, such as 3412, 3414 and 3416. In someembodiments, the tracking points may not appear on the display. Inanother embodiment, the tracking points may be rendered to the display.In some embodiments, if the tracking point is not located on the objectof interest, the user may be able to select the tracking point anddelete it or move it so that the tracking point lies on the object.

Next, an orientation of the mobile device can change. The orientationcan include a rotation through one or more angles and translationalmotion as shown in 3404. The orientation change and current orientationof the device can be captured via the IMU data from IMU 3402 on thedevice.

As the orientation of the device is changed, one or more of the trackingpoints, such as 3412, 3414 and 3416, can be occluded. In addition, theshape of surfaces currently appearing in the image can change. Based onchanges between frames, movement at various pixel locations can bedetermined. Using the IMU data and the determined movement at thevarious pixel locations, surfaces associated with the object 3408 can bepredicted. The new surfaces can be appearing in the image as theposition of the camera changes. New tracking points can be added tothese surfaces.

As described above, the mobile device can be used to capture images usedin a MVIDMR. To aid in the capture, the live image data can be augmentedwith a track or other guides to help the user move the mobile devicecorrectly. The track can include indicators that provide feedback to auser while images associated with a MVIDMR are being recorded. In 3406c, the live image data is augmented with a path 3422. The beginning andend of the path is indicated by the text, “start” and “finish.” Thedistance along the path is indicated by shaded region 3418.

The circle with the arrow 3420 is used to indicate a location on thepath. In some embodiments, the position of the arrow relative to thepath can change. For example, the arrow can move above or below the pathor point in a direction which is not aligned with the path. The arrowcan be rendered in this way when it is determined the orientation of thecamera relative to the object or position of the camera diverges from apath that is desirable for generating the MVIDMR. Colors or otherindicators can be used to indicate the status. For example, the arrowand/or circle can be rendered green when the mobile device is properlyfollowing the path and red when the position/orientation of the camerarelative to the object is less than optimal.

FIGS. 35A and 35B illustrate yet another example of generating anAugmented Reality (AR) image capture track including status indicatorsfor capturing images used in a MVIDMR. The synthetic image generated bythe AR system can consist of live image data from a camera augmentedwith one or more virtual objects. For example, as described above, thelive image data can be from a camera on a mobile device.

In FIG. 35A, an object 3500 a, which is a statue, is shown in an image3515 from a camera at a first position and orientation. The object 3500a can be selected via the cross hairs 3504 a. Once the cross hairs areplaced on the object and the object is selected, the cross hairs canmove and remain on the object as the object 3500 a moves in the imagedata. As described above, as an object's position/orientation changes inan image, a location to place the cross hairs in an image can bedetermined. In some embodiments, the position of the cross hairs can bedetermined via tracking the movements of points in the image, i.e., thetracking points.

In particular embodiments, if another object is moved in front of atracked object, it may not be possible to associate the target 3504 awith the object. For example, if a person moves in front of the camera,a hand is passed in front of the camera or the camera is moved so theobject no longer appears in the camera field of view, then the objectwhich is being tracked will no longer be visible. Hence, it may not bepossible to determine a location for the target associated with thetracked object. In the instance where the object reappears in the image,such as if a person that blocked the view of the object moved into andout of the view, then the system can be configured to reacquire thetracking points and reposition the target.

A first virtual object is rendered as indicator 3502 a. Indicator 3502 acan be used to indicate the progress in capturing images for a MVIDMR. Asecond virtual object is rendered as curve 3510. Third and fourthvirtual objects are rendered as lines 3506 and 3508. A fifth virtualobject is rendered as curve 3512.

The curve 3510 can be used to depict a path of a camera. Whereas lines3506 and 3508 and curve 3512 can be used to indicate an angle range forthe MVIDMR. In this example, the angle range is about ninety degrees.

In FIG. 35B, the position of the camera is different as compared to FIG.35A. Hence, a different view of object 3500 b is presented in image3525. In particular, the camera view shows more of the front of theobject as compared to the view in FIG. 35A. The target 3504 b is stillaffixed to the object 3500 b. However, the target is fixed in adifferent location on the object, i.e., on a front surface as opposed toan arm.

The curve 3516 with arrow 3520 at the end is used to indicate theprogress of the image capture along curve 3510. The circle 3518 aroundthe arrow 3520 further highlights the current position of the arrow. Asdescribed above, a position and a direction of the arrow 3520 can beused to provide feedback to a user on a deviation of the camera positionand/or orientation from curve 3510. Based upon this information, theuser may adjust a position and/or orientation of the camera while it iscapturing the image data.

Lines 3506 and 3508 still appear in the image but are positioneddifferently relative to object 3500 b. The lines again indicate an anglerange. In 3520, the arrow is about half way between lines 3506 and 3508.Hence, an angle of about 45 degrees has been captured around the object3500 b.

The indicator 3502 b now includes a shaded region 3522. The shadedregion can indicate a portion of a MVIDMR angle range currentlycaptured. In some embodiments, lines 3506 and 3508 can only indicate aportion of the angle range in a MVIDMR that is being captured and thetotal angle range can be shown via indicator 3502 b. In this example,the angle range shown by indicator 3502 b is three hundred sixty degreeswhile lines 3506 and 3508 show a portion of this range which ninetydegrees.

With reference to FIG. 36 , shown is a particular example of a computersystem that can be used to implement particular examples. For instance,the computer system 3600 can be used to provide MVIDMRs according tovarious embodiments described above. According to various embodiments, asystem 3600 suitable for implementing particular embodiments includes aprocessor 3601, a memory 3603, an interface 3611, and a bus 3615 (e.g.,a PCI bus).

The system 3600 can include one or more sensors 3609, such as lightsensors, accelerometers, gyroscopes, microphones, cameras includingstereoscopic or structured light cameras. As described above, theaccelerometers and gyroscopes may be incorporated in an IMU. The sensorscan be used to detect movement of a device and determine a position ofthe device. Further, the sensors can be used to provide inputs into thesystem. For example, a microphone can be used to detect a sound or inputa voice command.

In the instance of the sensors including one or more cameras, the camerasystem can be configured to output native video data as a live videofeed. The live video feed can be augmented and then output to a display,such as a display on a mobile device. The native video can include aseries of frames as a function of time. The frame rate is oftendescribed as frames per second (fps). Each video frame can be an arrayof pixels with color or gray scale values for each pixel. For example, apixel array size can be 512 by 512 pixels with three color values (red,green and blue) per pixel. The three color values can be represented byvarying amounts of bits, such as 24, 30, 36, 40 bits, etc. per pixel.When more bits are assigned to representing the RGB color values foreach pixel, a larger number of colors values are possible. However, thedata associated with each image also increases. The number of possiblecolors can be referred to as the color depth.

The video frames in the live video feed can be communicated to an imageprocessing system that includes hardware and software components. Theimage processing system can include non-persistent memory, such asrandom-access memory (RAM) and video RAM (VRAM). In addition,processors, such as central processing units (CPUs) and graphicalprocessing units (GPUs) for operating on video data and communicationbusses and interfaces for transporting video data can be provided.Further, hardware and/or software for performing transformations on thevideo data in a live video feed can be provided.

In particular embodiments, the video transformation components caninclude specialized hardware elements configured to perform functionsnecessary to generate a synthetic image derived from the native videodata and then augmented with virtual data. In data encryption,specialized hardware elements can be used to perform a specific datatransformation, i.e., data encryption associated with a specificalgorithm. In a similar manner, specialized hardware elements can beprovided to perform all or a portion of a specific video datatransformation. These video transformation components can be separatefrom the GPU(s), which are specialized hardware elements configured toperform graphical operations. All or a portion of the specifictransformation on a video frame can also be performed using softwareexecuted by the CPU.

The processing system can be configured to receive a video frame withfirst RGB values at each pixel location and apply operation to determinesecond RGB values at each pixel location. The second RGB values can beassociated with a transformed video frame which includes synthetic data.After the synthetic image is generated, the native video frame and/orthe synthetic image can be sent to a persistent memory, such as a flashmemory or a hard drive, for storage. In addition, the synthetic imageand/or native video data can be sent to a frame buffer for output on adisplay or displays associated with an output interface. For example,the display can be the display on a mobile device or a view finder on acamera.

In general, the video transformations used to generate synthetic imagescan be applied to the native video data at its native resolution or at adifferent resolution. For example, the native video data can be a 512 by512 array with RGB values represented by 24 bits and at frame rate of 24fps. In some embodiments, the video transformation can involve operatingon the video data in its native resolution and outputting thetransformed video data at the native frame rate at its nativeresolution.

In other embodiments, to speed up the process, the video transformationsmay involve operating on video data and outputting transformed videodata at resolutions, color depths and/or frame rates different than thenative resolutions. For example, the native video data can be at a firstvideo frame rate, such as 24 fps. But, the video transformations can beperformed on every other frame and synthetic images can be output at aframe rate of 12 fps. Alternatively, the transformed video data can beinterpolated from the 12 fps rate to 24 fps rate by interpolatingbetween two of the transformed video frames.

In another example, prior to performing the video transformations, theresolution of the native video data can be reduced. For example, whenthe native resolution is 512 by 512 pixels, it can be interpolated to a256 by 256 pixel array using a method such as pixel averaging and thenthe transformation can be applied to the 256 by 256 array. Thetransformed video data can output and/or stored at the lower 256 by 256resolution. Alternatively, the transformed video data, such as with a256 by 256 resolution, can be interpolated to a higher resolution, suchas its native resolution of 512 by 512, prior to output to the displayand/or storage. The coarsening of the native video data prior toapplying the video transformation can be used alone or in conjunctionwith a coarser frame rate.

As mentioned above, the native video data can also have a color depth.The color depth can also be coarsened prior to applying thetransformations to the video data. For example, the color depth might bereduced from 40 bits to 24 bits prior to applying the transformation.

As described above, native video data from a live video can be augmentedwith virtual data to create synthetic images and then output inreal-time. In particular embodiments, real-time can be associated with acertain amount of latency, i.e., the time between when the native videodata is captured and the time when the synthetic images includingportions of the native video data and virtual data are output. Inparticular, the latency can be less than 100 milliseconds. In otherembodiments, the latency can be less than 50 milliseconds. In otherembodiments, the latency can be less than 30 milliseconds. In yet otherembodiments, the latency can be less than 20 milliseconds. In yet otherembodiments, the latency can be less than 10 milliseconds.

The interface 3611 may include separate input and output interfaces, ormay be a unified interface supporting both operations. Examples of inputand output interfaces can include displays, audio devices, cameras,touch screens, buttons and microphones. When acting under the control ofappropriate software or firmware, the processor 3601 is responsible forsuch tasks such as optimization. Various specially configured devicescan also be used in place of a processor 3601 or in addition toprocessor 3601, such as graphical processor units (GPUs). The completeimplementation can also be done in custom hardware. The interface 3611is typically configured to send and receive data packets or datasegments over a network via one or more communication interfaces, suchas wireless or wired communication interfaces. Particular examples ofinterfaces the device supports include Ethernet interfaces, frame relayinterfaces, cable interfaces, DSL interfaces, token ring interfaces, andthe like.

In addition, various very high-speed interfaces may be provided such asfast Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces,HSSI interfaces, POS interfaces, FDDI interfaces and the like.Generally, these interfaces may include ports appropriate forcommunication with the appropriate media. In some cases, they may alsoinclude an independent processor and, in some instances, volatile RAM.The independent processors may control such communications intensivetasks as packet switching, media control and management.

According to various embodiments, the system 3600 uses memory 3603 tostore data and program instructions and maintained a local side cache.The program instructions may control the operation of an operatingsystem and/or one or more applications, for example. The memory ormemories may also be configured to store received metadata and batchrequested metadata.

The system 3600 can be integrated into a single device with a commonhousing. For example, system 3600 can include a camera system,processing system, frame buffer, persistent memory, output interface,input interface and communication interface. In various embodiments, thesingle device can be a mobile device like a smart phone, an augmentedreality and wearable device like Google Glass™ or a virtual reality headset that includes a multiple cameras, like a Microsoft Hololens™. Inother embodiments, the system 3600 can be partially integrated. Forexample, the camera system can be a remote camera system. As anotherexample, the display can be separate from the rest of the componentslike on a desktop PC.

In the case of a wearable system, like a head-mounted display, asdescribed above, a virtual guide can be provided to help a user record aMVIDMR. In addition, a virtual guide can be provided to help teach auser how to view a MVIDMR in the wearable system. For example, thevirtual guide can be provided in synthetic images output to head mounteddisplay which indicate that the MVIDMR can be viewed from differentangles in response to the user moving some manner in physical space,such as walking around the projected image. As another example, thevirtual guide can be used to indicate a head motion of the user canallow for different viewing functions. In yet another example, a virtualguide might indicate a path that a hand could travel in front of thedisplay to instantiate different viewing functions.

1. A method comprising: determining an object model by applying a neuralnetwork to a first plurality of images to create a three-dimensionalskeleton of a designated object, each of the first plurality of imagesbeing captured from a respective viewpoint, the object model including aplurality of object model components, each of the images correspondingto one or more of the object model components, each of the object modelcomponents corresponding to a respective portion of the designatedobject; determining respective component condition information for oneor more of the object model components using the plurality of images,the component condition information indicating a characteristic ofdamage incurred by the respective object portion corresponding with theobject model component; converting the characteristic of damage into aheatmap visual representation associated with estimated damage to therespective object portion; overlaying the heatmap onto a Multi-ViewInteractive Digital Media Representation (MVIDMR) associated with thedesignated object; and storing the component condition information on astorage device.
 2. The method of claim 1, wherein the first plurality ofimages is used to estimate one or more two-dimensional skeleton jointsto create the three-dimensional skeleton.
 3. The method of claim 1,wherein the characteristic of damage includes an estimated probabilityof damage to the respective object portion and an estimated severity ofdamage to the respective object portion.
 4. The method of claim 1,wherein the MVIDMR is generated using the first plurality of images. 5.The method recited in claim 1, the method further comprising:determining aggregated object condition information based on thecomponent condition information, the aggregated object conditioninformation indicating damage to the object as a whole.
 6. The methodrecited in claim 5, the method further comprising: based on theaggregated object condition information, determining a standard view ofthe object that includes a visual representation of damage to theobject.
 7. The method recited in claim 6, wherein the standard view ofthe object is selected from the group consisting of: a top-down view ofthe object, a multi-view representation of the object navigable in oneor more directions, and a three-dimensional model of the object.
 8. Themethod recited in claim 1, wherein determining the object model includesestimating pose information for a designated one of the plurality ofimages, the pose information including a location and angle of a camerawith respect to the designated object for the designated image.
 9. Themethod recited in claim 8, wherein determining the object model includesdetermining a three-dimensional skeleton of the designated object basedon two-dimensional skeleton joints and the pose information.
 10. Themethod recited in claim 9, wherein the plurality of object modelcomponents are identified based at least in part on thethree-dimensional skeleton of the designated object.
 11. The methodrecited in claim 1, wherein a designated one of the plurality of objectmodel components corresponds with a designated subset of the images anda designated portion of the object, the method further comprising:constructing a multi-view representation of the designated portion ofthe object at the handheld recording device based on the designatedsubset of the images, the multi-view representation being navigable inone or more directions.
 12. The method recited in claim 1, whereindetermining the component condition information comprises: applying aneural network to a subset of the images corresponding with therespective object model component.
 13. The method recited in claim 12,wherein the neural network receives as an input depth informationcaptured from a depth sensor at the handheld recording device.
 14. Themethod recited in claim 12, wherein determining the component conditioninformation further comprises: aggregating neural network resultscomputed for separate images corresponding with the respective objectmodel component.
 15. The method recited in claim 12, the method furthercomprising: constructing a multi-view representation of the designatedobject at the handheld recording device based on the plurality ofimages, the multi-view representation being navigable in one or moredirections.
 16. The method recited in claim 12, wherein the object is avehicle, and wherein the object model includes a three-dimensionalskeleton of the vehicle, and wherein the plurality of object modelcomponents include each of a left vehicle door, a right vehicle door,and a windshield.
 17. The method recited in claim 12, determining thatthe plurality of images exhibit a coverage level that is beneath adesignated threshold; and providing a recording guidance instruction tocapture additional image data.
 18. The method recited in claim 17,wherein the plurality of images are captured at a first level of clarityor detail, and wherein the recording guidance instruction indicates asecond level of clarity or detail.
 19. One or more non-transitorycomputer readable media having instructions stored thereon forperforming a method, the method comprising: determining an object modelby applying a neural network to a first plurality of images to create athree-dimensional skeleton of a designated object, each of the firstplurality of images being captured from a respective viewpoint, theobject model including a plurality of object model components, each ofthe images corresponding to one or more of the object model components,each of the object model components corresponding to a respectiveportion of the designated object; determining respective componentcondition information for one or more of the object model componentsusing the plurality of images, the component condition informationindicating a characteristic of damage incurred by the respective objectportion corresponding with the object model component; converting thecharacteristic of damage into a heatmap visual representation associatedwith estimated damage to the respective object portion; overlaying theheatmap onto a Multi-View Interactive Digital Media Representation(MVIDMR) associated with the designated object; and storing thecomponent condition information on a storage device.
 20. A mobilecomputing device comprising: a camera configured to capture a video of adesignated object as it moves through space around the designatedobject; a processor configured to: determine an object model by applyinga neural network to a first plurality of images to create athree-dimensional skeleton of a designated object, each of the firstplurality of images being captured from a respective viewpoint, theobject model including a plurality of object model components, each ofthe images corresponding to one or more of the object model components,each of the object model components corresponding to a respectiveportion of the designated object; determine respective componentcondition information for one or more of the object model componentsusing the plurality of images, the component condition informationindicating a characteristic of damage incurred by the respective objectportion corresponding with the object model component; convert thecharacteristic of damage into a heatmap visual representation associatedwith estimated damage to the respective object portion; overlay theheatmap onto a Multi-View Interactive Digital Media Representation(MVIDMR) associated with the designated object; and a storage deviceconfigured to store the component condition information.
 21. The mobilecomputing device recited in claim 20, wherein the processor is furtherconfigured to: determine aggregated object condition information basedon the component condition information, the aggregated object conditioninformation indicating damage to the object as a whole; and based on theaggregated object condition information, determine a standard view ofthe object that includes a visual representation of damage to theobject.